The whole point of the excersice is to get rid of the dynamic_module_makefile, since it invariably does not work if you change your system in any way.
The example is as compact as it is because the CHANGES file is not really intended to be 10000 lines long..
You are, as is stated in the entry, free to use configure.in with friends. But please do avoid using the dynamic_module_makefile and similar things. A set of useful configure-macros might be good to have to shorten your configure.in (but really, it's not really all that needed, the only thing you need to find out is the location of whatever library your module use, if any, and how to compile shared library code, which is trivial on most systems nowdays, and there already exist finished macros for that kind of things)
It's not really nessesary to compile your module with the exact same flags that were used when pike was compiled, and it tends to break things (libgcc moved? Broken. Gcc updated, thus a different version on libgcc? Broken. New library installed? You won't find it if pike checked for it at compile time, etc)
There are basically only two things you need to know from pike, and one of them is rather optional:
1: Where is the pike include files, and any special defines needed? pike -x cflags
2: Where should the module be installed to? pike --show-paths or use pike -x module ('new' style)
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.