Because you didn't meditate. And you didn't even make it clear that you were seeking wisdom from others. You just pointed and gesticulated.
As for the module, I was struck with the author's need to include the quotes. It struck me as a demonstration of "I'm so arrogant, I'll include the quotes decrying my arrogance to demonstrate the input I was able to effectively ignore due to my arrogance." Meh.
The module name sucks. All-lowercase. Invents a new top-level namespace that sucks as a top-level namespace. The name maxes out on cuteness at the expense of giving the audience a good clue as to the purpose of the module.
If it were even called Devel::CommonSense, then I'd have little criticism to offer.
It does use less memory than strict/warnings :)
Actually, for the vast majority of the Perl world, it uses more memory, because it doesn't prevent strict/warnings from being loaded. So, in the author's mindset, it kills trees and kittens... perhaps just not his trees/kittens. Lousy justification.
The customization of warnings is the interesting part. Not something I'll use myself for several reasons.
I disagree that making warnings fatal is a great idea. Even if it magically only makes bugs fatal, I expect it to be a mixed blessing. Fatality can be useful in making bugs extra obvious, forcing them to be fixed (or at least worked around). But warnings are not particularly hard to notice so the added benefit of fatality during development / testing is not clear-cut. Meanwhile, continuing on past a subtle bug can be useful once in Production. The problem with warnings is that they tend to depend very much on context so fatal errors like those exposed by strict.pm are almost always found during development and testing while warnings are much more likely to survive to Production, IME. And a fatal warning is almost always a serious impact in Production while the subtle bug is often the better choice. But it is a good experiment to try.
Also, the module's role is unsettled. If I started using it now, an upgrade to it could easily take a warning that was previously being ignored and instead make it fatal.
The horrid name and the section devoted to demonstrating the author's arrogance are also among the reasons I'm unlikely to use it, of course.
Update: Oh, and I also often (usually, these days) program in a mode where 'undef' warnings indicate a mistake. Yes, the signal-to-noise ratio of that particular warning is likely the worst of any Perl warning. If you didn't consciously choose to use 'undef' as an indicator of "I forgot to initialize that", then it is an annoyingly useless warning. Even when you've made that choice, it does it's best to tempt you to unmake that choice.
But even more so I wish I could use autovivification as an indicator of a mistake. I often (usually, these days) program in a mode where autovivification is a mistake. I just can't convince Perl to tell me when it resorts to autovivification. I've long wanted a "no autovivification;" pragma.
Actually, one should have the choice to make it always fatal or just make it always a warning, including controling whether using undef as a reference in a non-lvalue context should be considered a fatal "symbolic reference" under "use strict 'refs'" (as the module's author rightly complains about).
I guess that is another place where I disagree with the module's author. Although I sometimes dislike that "use strict 'refs'" makes that particular form of autovivification fatal, I don't consider it worth throwing out the "use strict 'refs'" baby to get rid of that particular autovivification bathwater.