If it's dangerous, note it in the class/method Javadocs, don't just blindly slam the door shut.

It often eliminates the only practical solution to unforseen problems or use cases.

This is especially useful for UI library components, as it is generally unknown which events will be required from them for all desired use cases. For example, if a Button component only forwards a click event, then no use case that requires the mouseover or the keypress event can be used with it.

Hobbes and Rousseau told their contemporaries things that werestartling, profound and opened new doors of the imagination. Nowtheir ideas are just tired common sense. There’s nothing in them thatjustifies the continued simplification of human affairs. If socialscientists today continue to reduce past generations to simplistic,two-dimensional caricatures, it is not so much to show us anythingoriginal, but just because they feel that’s what social scientists areexpected to do so as to appear ‘scientific’. The actual result is toimpoverish history – and as a consequence, to impoverish our senseof possibility.

This is a very dangerous practice as each optimization means making assumptions. If you are compressing an image you make an assumption that some payload can be cut out without seriously affecting the quality, if you are adding a cache to your backend you assume that the API will return same results. A correct assumption allows you to spare resources. A false assumption introduces a bug in your app. That’s why optimizations should be done consciously.

but the advantage is the "functional style" with its strict separation of scopes = less attack surface for bugs

If we don’t force kids to come to school in order to change their ‘mindsets’, why ARE they here? 

The subjects of our deliberation are such as seem to present us with alternative possibilities