I definitely agree with you on the reasons why concrete performance rules/documentation is dangerous - I historically have tried to advocate for better introspection/debugging tools instead of just lists/documents. But so far the reaction to those has been pretty cold; it seems as if most engine devs I speak to view introspection tools/APIs as equivalent to documenting (and thus locking in) internals and runtime design details. I can understand how shipping a product like this as a part of a large software org is pretty hard - it's difficult to establish how many customers it has and what the benefits will be.

Not really sure how we get out of the spot we're in, unfortunately - in practice JS optimization is a mix of black magic and cargo cult wisdom that can become outdated as engines improve, and I can see that causing a lot of long term drag on productivity as engine authors have to keep tuning their engines for bad code.

I hope you keep getting traction on exposing developers to V8 internals; the stuff I've learned about both V8 and spidermonkey internals has been very useful so far - my complaint is largely that the learning process is difficult, not that there's anything wrong with your codebase :) I love that so many of the v8 JS builtins are self-hosted in JS instead of C++ - makes it much easier to peek under the hood and figure out what they're doing!