(I work on React.) Most of our users use Babel so it would be irresponsible for us to not consider how React and Babel play together; if we didn't we'd quickly get into a situation where no one can use React because their setups are incompatible.

For what it's worth, if we found while developing React that Babel was compiling something in a problematic way and we had a better suggestion for the compiled output, we'd certainly see if we could get it fixed upstream. In this case the Babel output for classes is pretty reasonable so there's nothing to change.

We did briefly consider if it made sense to require every function component to be written using an arrow functions and asking Babel to delete the .prototype property from every compiled arrow function (compiling a = () => ... into something like a = function() { ... }; a.prototype = undefined;). We eventually decided that the .prototype.isReactComponent compromise described in the post was a better result overall, both for authoring ergonomics and runtime performance.

Transpiling ES6 to ES5 is a hard problem, and I believe it's impossible to be 100% correct unless you ship a full JS interpreter written in JS (which would have terrible performance). As a result, Babel and TypeScript both have to make pragmatic tradeoffs, and you can certainly find plenty of cases of non-spec-compliance if you go looking for them. Sometimes transpilers diverge from the spec for performance reasons, sometimes because following the spec would be too hard to implement, and sometimes because there isn't any (reasonable) way to follow the spec. This is especially true with low-level reflection operations like seeing if something is a class or a function.