Disclaimer: I'm one of the authors.
Really, what is wanted is a set of books, each for a different required confidence level. This would make an excellent book #1 in the set. Book #2 onwards would need to add to the book before, explaining where a certain methodology simply won't work at the more stringent level and what you replace it with. For example, their compliant solution on page 25 for doPrivilegedAction() is good for a basic level of confidence but has flaws. There's magic numbers (an 8 for the maximum length of a username), the program flow isn't great (check for a maximum length doesn't actually trip an exception), some parameters aren't sanity-checked (the password is passed straight to the hash function without knowing if it meets the size requirements for the function or if there's anything in the string that might break things). It's perfectly good for a basic level of good practice, but I wouldn't consider it adequate for more advanced levels.
I'm not sure what you are referring to on page 25, there is no doPrivileged() block there. But go ahead & contact me with specific criticisms or comments on the rules.
Some of the problems you cite arise from the main purpose of the code examples, which is to be illustrative, rather than to be functional. For example, I'll agree that magic numbers in code are generally a bad idea, and should be replaced with constants. In fact, we considered adding a rule about this to the book, and nixed it because that is purely a maintainability issue, with no direct ramifications to security. (That is, you'd have to work hard to contrive an example where failing to use magic numbers makes your program vulnerable rather than just buggy.)
Using 'magic numbers' also makes the code bigger, and a little harder to read. For code whose purpose is to work properly, this extra code size is no big deal, but when the code's purpose is to serve as an illustration in a book, this bloat is more problematic. If the code has to appear on a PowerPoint slide, this bloat can be critical.
(Having everything in one single book and coding to an insanely high standard is why the DoD's efforts for higher quality code ultimately failed. It had nothing to do the limits of what people can do, it had everything to do with what people have time to do. You need a good baseline and build from it.)
The thing that concerns me is that Oracle will probably consider this sufficient for everyone, which it isn't. The standards are not even up to the quality needed by e-Commerce and should not be used directly from this book for that purpose. This is a foundation layer, it isn't the entire edifice.
I suspect the ediface you are imagining is a tower of babel...it will never be complete. True security is an impossible dream, that we can asymptotically approach yet never attain. In this book, we tried to focus on the insecure coding practices being made today; we ignored 'theoretical' insecure coding practices that aren't being widely done today. Mainly to keep the project a manageable size :)