There's 2 fundamental problems with most 'develop live in the browser' systems that i've seen. Note that the LightTable + ClojureScript combo is an exception from this, even though that requires writing your app in a certain way.
My general argument is not that it's impossible to do this. It is that there's a lot more complexity to exisiting JS apps, and for this to work as flawlessly as all those demos say, Apps need to be written with hot code swapping in mind.
The mechanism itself for redefining a piece of code is not always so easy. Let's say your app is a browserify build. Sure, if you're redefining one (public) method on an object, you can find the object and swap out the method on the obj itself, or on its prototype. But how do you go about with more advanced patterns? Maybe a module is exposing 1 public method, that has 3 methods internally. That method is then passed as a value into other modules. Now all of a sudden, modules not only need to re-define themselves, they also need to redefine the modules that depends on them. With various module system and different ideologies on how much to make public, this becomes more complex than those systems assume.
Let's take an example: To be technically able to swap out code today, the editor would have to do 3 things:
1. Detect a file change.
2. Redefine the modules that uses this file
3. Reboot the app
Note that the process is about the same whether you're doing react, angular, clojurescript, etc. I'm not saying this is a drawback, im saying most JS SPA:s arent written for this: It requires you to write like 5 small apps on a page instead of 1 big one, so you can re-initialize those widgets individually.
If this takes on as a trend, new patterns will emerge for development that will make this more feasible. With the current JS patterns that are taught (module pattern being the main perpetrator), it's not so feasible.