Ok - I think this article pitches the wrong thing (or at least buries the lede).
I think the key point is that by using overrides, he can basically implement a deployed change that uses production data, but without having any access or control over production infrastructure, and with no risk for other users.
Lots of folks have correctly pointed out that running locally is essentially a solved problem. He can do it against prod data, because he's overriding the prod configuration.
I've done exactly this for non-browser (and some browser) applications before (using local MITM proxies) but it's nifty that chrome lets you skip the certificate headaches and just loads a resource from disk.
I find it most handy for debugging, especially if you've got the sourcemaps available (infinitely easier without minified code though). In that sense the developer console is an underutilised tool when trying to nail down problems, especially in highly stateful SPAs and I tend to use it as a REPL before I start putting pen to paper in my editor. So much easier than trying to create the ideal state locally if you already have it handy somewhere else.
Although I notice in general that this style of development (or its close friend REPL-driven development) is hard to teach for people heavily accustomed to print debugging or even TDD.
I think the key point is that by using overrides, he can basically implement a deployed change that uses production data, but without having any access or control over production infrastructure, and with no risk for other users.
Lots of folks have correctly pointed out that running locally is essentially a solved problem. He can do it against prod data, because he's overriding the prod configuration.
I've done exactly this for non-browser (and some browser) applications before (using local MITM proxies) but it's nifty that chrome lets you skip the certificate headaches and just loads a resource from disk.