My argument is that you should be aware of what is required to implement a language (at least to some extent), and what may go against implementation assumption

My argument is that you should be aware of what is required to implement a language (at least to some extent), and what may go against implementation assumptions. These things are always a tradeoff, and if you mutate objects enough through their lifespan then maybe implementations will move more towards looking at the methods attached to an object, and ignore the shape of the data except when accessing a property (the methods are already normally stored off to one side on the assumption that you won't change them), but that will either make objects larger (need to store a ref to the shape and to the methods per object) or require an extra indirection (need to follow from the shape to the methods) so may incur a slight overall performance penalty. Yes, we are all in the same game as GL driver developers and game devs, and that goes for all language implementations. The fine details of what gets optimised best may change from VM to VM, and from release to release, but it's important to understand the general assumptions that these systems are built around, because they don't change quickly. In general dynamic languages that allow properties to be created and deleted on individual objects are a complete PITA to optimise, and more generally mutability of classes makes stuff harder, so in general even though you have these abilities in JS and other languages your code will often perform better if you limit your use of them, especially in areas where performance is critical. This doesn't mean you shouldn't use those mutability features, but you should have some notion of the cost you might be incurring.