I'm also somewhat skeptical that every new web app needs to be an SPA but one thing I'm 100% sold on as a generalist with the bulk of his experience on the client side is that a service-oriented architecture that hands off raw data rather than HTML to the client is the way to go whether you're loading prebuilt pages/views from the server and doing a lot of dynamic stuff with data after page load or building almost everything 100% with JavaScript.
The reasons this is preferable to a client-side dev are much the same as the reasons nobody wants HTML in the database. What's the client-side dev supposed to do when they want to resort a table for instance when they've been handed HTML? The performance cost of handling all that on the client is trivial compared to making another server request to do that for you. Also, HTML-building is pretty well-covered in JS-land. Sorting data and building new HTML table rows out of it is pretty trivial work for an experienced client-side dev.
And of what use is the back end architecture to a front end for another device that might need to do something exotic like implement widgets that are 100% canvas or a totally different HTML structure? Why should a client-side dev have to load up visual studio or knock on the back end devs door to make a strictly presentational tweak?
As for your concerns about the loss of strongly typed template validation, trust me when I say that if you're dealing with a competent client-side dev, you will find no .NET framework or visual studio tool that is more coal-to-diamond-to-dust-crushingly anal about well-formed, valid HTML than s/he is.
From the full-stack perspective, I like it because it means I'll never have to fish for business or app logic some yutz decided to drop into the templating layer. Not to mention the per-user load it takes off of your servers while in many cases actually improving load experience for the user in modern browsers with modern computers.
I think it's also easier to reason about the back end architecture when you've fully isolated it from all the presentation stuff. You're no longer grabbing data to mash it into some HTML. You're pulling it together to create an implementation-independent data structure that concerns itself more with general use than what's going to be done with it on the other side. IMO, that tends to lead to more consistency in how things are handled since the data is now an end goal rather than the second to last step of a process and there's fewer opportunities for unrelated concerns to get their wires crossed.
Since you are not developing a website or a web application, but a desktop application which stores its data on a server, there are indeed a few layers you can skip.
A common approach, in this situation, is to use web services.
When a service should be lightweight and interoperable (that is, you can use it with ease from virtually every programming language), the service can take a form of REST. The drawback is that not every server-side language makes it possible to create REST services painlessly, without writing too much code.
Another form a web service can take is SOAP. In .NET Framework, this was a de facto standard option for web services for a long time, although recently, there is a major shift towards REST; for instance, SharePoint itself relies more and more on REST instead of previously ubiquitous WCF services. I could imagine that the situation is similar with Java and PHP.
The benefit of SOAP is that you probably don't have to write any code at all. In .NET Framework, you declare your web service interfaces server-side and let the framework generate the WSDL (the detailed schema of the service) and process the requests and the responses. Then you import the service client-side, without the need to write a single line of code.
The drawback of SOAP is that it is usually much heavier compared to REST. Responses are also usually larger, which impacts the bandwidth.
In your case, consider the web service as an interface to your database. Since you don't want anyone to be able to select everything from your users' table or delete all your tables, the web service is a way to tell who can access what.
This is different from simply giving access to an SQL database with a fine-grained configuration of permissions, so that a given user can access and do only a very limited amount of things. With a web service, you can also sanitize inputs, control how much resources are accessed by a user, use cache to boost performance, access resources outside the database, etc.
Of course, you can simply even the step of writing the service interface if the only thing you need is to bind the service to the database. In .NET Framework, WCF Data Services are used for that (the project is originally called Microsoft Astoria; search for this name if you want articles which are not too technical). I'm sure Java and PHP have something similar.
Best Answer
That's a good summary.
Note that if you're front-loading functionality into your browser page, there may be little difference between your front-end and back-end javascript. For example, I worked on an app that did pathfinding through maps of airports. I did it in javascript in the browers to keep it fast & save a round trip. My code to do the graph traversal didn't make any reference to the browser or events, so it could have run on either front end or back end. I just put it on the front end to speed things up.
That's an addendum to your summary, though, rather than a contradiction.