Isomorphic javascript doesn't mean that you HAVE to run all your code interchangeably. It's more about organization than a hard and fast rule. It means using the same package manager for frontend code as server side code (npm) -- tools like browserify and libraries that provide for design patterns that can be used with a DOM, or without one. It means treating javascript as javascript, not having separate repo's for frontend code and backend code.
You still have to logically organize your application and make good choices about your code organization, as well as separation of concern. Interaction should always happen on the client.
Also, the technique mentioned in the article about bootstrapping data into the initial page load is quite old and known about, and not a revelation. It does save one request round trip, which could potentially speed up your application by that one request (usually session data or user bootstrap data), but is not the silver bullet in solving all performance problems as the OP implies.
I think having a separate repo for the frontend and backend is important. It is the same separation I want for my Android and iOS code. If they were mixed with the backend it becomes messy. So the frontend is just another client like other platforms.
I think isomorphic JavaScript applications are going to replace the current frontend paradigm. Microservices are becoming more popular, so imagine an isomorphic JavaScript application as a frontend consumer of many backend microservices. Plus there are a slew of security considerations that cannot be solved with current frontend JavaScript.
For instance, how do I call a protected API without leaking the API credentials to the consumer? Currently you can do this with trusted hardware or the traditional server side rendering. An isomorphic JavaScript application can solve this problem using server side rendering without needing a separate backend.
This is precisely what we're moving towards right now. It allows us to break away from our current, sub-optimal backend server serving up all the services to an isomorphic JS app that consumes variety and spits back out results from API calls. It allows for great flexibility -- not to mention speed and consistency.
You still have to logically organize your application and make good choices about your code organization, as well as separation of concern. Interaction should always happen on the client.
Also, the technique mentioned in the article about bootstrapping data into the initial page load is quite old and known about, and not a revelation. It does save one request round trip, which could potentially speed up your application by that one request (usually session data or user bootstrap data), but is not the silver bullet in solving all performance problems as the OP implies.