The OP glossed over managing styles and i18n between embedded JS apps and the host app. I'm not sure if there is a way to create strictly isolated CSS in pure server rendered applications without managing naming your own selectors manually. If you build tiny JS apps into your server rendered apps, you'll have to keep the styling for the JS app either in the main app, or bundle it into the embededded JS. If you bundle it into the embedded JS, you'll end up with two styling pipelines, which could make it more difficult to share variables and constants between the two, if you put the CSS rules for the embedded app in the host app, then you have to change the host app CSS for changes in the child app, which means the two might need to be in the same repo. This gets especially more difficult with advances in UI and interaction design which lean more heavily on state based animation. In those cases, we HAVE to have CSS related to animatable elements that are based on application state within the embedded JS application, then you'll really have an issue with having two pipelines. There are similar issues for i18n, asset bundling, accessibility auditing, and testing.
Given all the complexity of managing multiple pipelines for simple and complex pages, it seems to make sense to avoid that complexity by adopting a single pipeline that ensures browser compatibility, testing, i18n, accessibility and performance optimizations are consistently applied and centrally maintained.
Which might imply , if _any_ of your app requires complex presentation/interaction, it might be better to just build the entire app using the same framework.
Unfortunately, even if your app doesn't currently have complex functionality or interactions, doesn't mean you can guarantee it won't ever. Investors are known for pushing products to innovate, pivot, and adapt. Which implies that avoiding SPAs is a privilege for app developers and teams who have absolute control over their product and won't ever be forced to build more complex products.
The Op also doesn't address how having frontend dedicated ecosystems might affect hiring, or influence performance. I remember the days of having 20 instance variables set within a rails action and each of them being deeply coupled into the Erb template. Having a clear client server separation at least forces one to use an API, which can make caching easier by separating the caching of presentational and data elements. Also, the semantics of each server side templating language are quite different. E.g , slim vs liquid vs haml vs ejs. Using server side templates requires frontend developers to be much more versed in both templating languages and understanding the tiny bits of embedded server side code. I don't imagine too many front end folks jumping to learn scala, clojure or Haskell. However, if the client and server are separate than that means a scala shop can focus on the API and hire a frontend dev with no experience in the server side stack.