I think though, that you're over-simplifying the situation. For simple modules that you don't intend to distribute, it's possible that this new system will work just fine. However, there are a large number of useful targets in dynamic_module_makefile that allow external modules to be distributed and built in a consistent manner.
Most of the Makefiles I write using dynamic_module_makefile are less than 10 lines long, as are the configuration scripts. I don't see how throwing all of that away makes life better; perhaps some things are better, but many others certainly won't be.
To be sure, it's a pain that there are cflags embedded in the installation, and it's a pain to update them when things change (which frankly doesn't happen that often for me). I always include checks for any libraries potentially required in modules I write, I'd guess that it's a better practice to do that rather than asssume that Pike will have found them previously.
Again, I think the "definitiveness" of the statements made regarding this new system should be altered appropriately, otherwise there is a very real risk of destroying the delicate balance of the external module world.
The idea with the minimal example is to show that if you want to write a small module for your own use, you don't really need 100 lines of configure.in and the mess that is dynamic_module_makefile.