All of the main SPA frameworks like Ember, React and both versions of Angular come with a router that allows for the creation of Restful Urls (React via a separate react-router library).

You can create Restful urls as you navigate through the app: /customers for a list of customers and /customers/:customerId for a detail containing a customer. If you want to make the SPA deep linkable, you need to pass an Id in the Url and load the data from the backend at the start of the route.

I’m not really sure what you mean by a SPA not being linkable, or that its too much work to make it so. Isn’t it just a matter of using the router’s most commonly used functionality? These are not edge cases, its the bread and butter of routing.

For rendering on the server, it means you need to send the html over the wire each time and patch parts of the page that changed. This causes issues like loss of focus if something had the focus in the part of the page that was swapped out by a new version of html that arrived from the server.

There are many common use cases with some user interactivity for which server-side rendering with progressive enhancement is not sufficient.

I think a SPA that only receives data on the form of JSON over the wire is easier to debug and understand, and covers more frequently needed use cases.

Using less technologies and having a clear separation of where they are used is a good thing as it simplifies the project and its learning curve. Why use a mix of client and server side rendering, if using client side rendering only covers more use cases? Why use two technologies instead of one.

If multiple developers need to work on different screens, they edit different HTML / Js files depending on the screen. How is that a team scalability issue or how moving that to the server would improve upon it.

You mention SPA applications are bloated. If you put in jQuery for a progressive enhancement approach, the size of the payload is almost an order of magnitude higher than using a SPA framework.