i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code.

sure you can put everything in one file, but the number of files is a meaningless metric. more useful is the number of functions and abstractions. an API is an abstraction. you can do away with that if you generate html in the backend, but the price you pay is with a much closer coupling of interface and business logic that will make future changes harder. in any sufficiently large site you can't afford that and you end up rewriting your site to create the same architectural complexity simply because you need it.

SPA frameworks query the server for JSON and then render HTML right?

Simpler in the sense of what? You prefer to not have all of the variables available when you render HTML? It's simpler to only render client side HTML and to query 4 different AJAX endpoints for resources?

Why are you trying to separate business and interface logic? Why are you displaying anything that the business logic doesn't understand?

The entire point of good code is that I can edit 1 file instead of editing 3.

Back end frameworks don't help you organize code? That's kind of their point?

The end result looks very similar to the server side frameworks of old, so it's a bit of a circular evolution. I think only using one programming language (the one that is part of the web platform) and a solid, template free component framework make it incrementally better though.

You can still and should have an API but it will be an internal one(in-process, not at the network boundary).

The code inside the API is an abstraction.