This is because Object.observe was removed from the web platform, while DevTools frontend code deployed uses it.

The workaround you mentioned is exactly what I would suggest to do. Or switch to the newer version of CEF (based on Chrome 52+) if possible.

Sorry for inconvenience. Thank you for reporting the bug!

Can we revisit this a bit? As far as I can see there is a compatibility path injected when chrome://inspect is used to remotely debug Android devices, even with long-obsolete devtools frontends. Object.observe emulation is one of the parts of it. See //content/browser/devtools/devtools_frontend_host_impl.cc

Would it be possible to allow arbitrary remote debugging sessions to go through that compatibility path?

The problem here is that browser doesn't know this is a debugging session. It's just an url served from localhost, it even talks to debugging target in different browser.
I think it's possible to write a simple extension which injects a copy of third_party/WebKit/Source/devtools/front_end/devtools.js file as a content script before specific url is loaded in the browser. Does that help in your usecase?

Could that extension access the exact evtools.js file embedded in the browser? If not, it will be a burden to keep everything in sync.

In any case, it seems a bit odd that desktop-to-desktop remote devtools gets the second-class "get an extension" treatment, while desktop-to-android works out of the box via chrome://inspect. I was thinking more along the lines of having a "direct connection" feature in chrome://inspect to allow connecting to a debugging port without requiring it to be a discovered android device. Do you think that would be acceptable / feasible?

Sure this sounds reasonable! In fact, we already have "--remote-debugging-targets=<host>:<port>" switch, and targets added this way should appear on chrome://inspect under Devices (not the best place, but at least something). From that point, any compatibility should work as designed.
Unfortunately, making this work automatically is tricky, so we rely on user passing correct flags.

"--remote-debugging-targets=<host>:<port>" would be great but it seems it only partially works for me.

When I start Chrome with --remote-debugging-targets=localhost:9222 and the target old-chrome with 9222 as the remote debugging port, I see the open tabs in chrome://inspect Devices tab, I can open/close tabs, but clicking Inspect on any tab doesn't do anything :(

51.0.2704.79 Ubuntu 14.04 (64-bit) connecting to 48.0.2564.0 on the same machine.

I see the tab being "focused" and not "inspected"

Issue from comment #6 seems to have been fixed since Chrome 52.

eostroukhov: Doesn't work for me. Clicking inspect focuses / switches tabs on the remote when I use 52.0.2743.116 or 53.0.2785.70 (remote is 48.0.2564.0), no devtools.

This does not seem like a Chrome issue - it is caused by an external application.

There is no external application involved here. The bug is about a remote debugging where a hosted devtools frontend becomes incompatible with the newer browser, and problems trying to trigger a compatibility path.