Minecraft modding is changing far too fast, by the time a book was written, edited, and published, it'd likely be largely obsolete, by my judgement. In fact just today the release of Minecraft 1.6 has pretty much obsoleted "jarmods" (direct replacement of classes in the minecraft.jar) by Mojang's new launcher, not to mention a brand new resource pack system obsoleting texture packs, as well as a large amount of internal refactoring.
This pattern has repeated throughout Minecraft's release cycle. Though with Minecraft 1.0 it is no longer considered in "beta", each major version has brought incompatible changes. Mojang doesn't use semantic versioning, needless to say. Had a book been written around 1.2, it would have undoubtedly focused on the singleplayer/multiplayer split, and the steps needed for modders to develop SSP-only or SMP-compatible mods, but this distinction was blurred or eliminated in 1.3. 1.3 was mostly a dead zone for modding, only to come back in 1.4. With 1.4 we saw the introduction of new server implementations or administration mods, combining either analogous functionality or proper support for both leading modding frameworks, Forge and Bukkit (including MCPC+, BukkitForge, ForgeEssentials, etc.).
Modding toolkits come and go: about a mere year ago, you might be modding with ModLoader, ModLoaderMP, AudioMod. Or pure Minecraft Coder Pack (MCP), with no APIs. Or lesser-known custom APIs. Nowadays, Forge ModLoader has basically taken over ModLoader, and many modders have been moving to Forge for compatibility and other reasons. IndustrialCraft, BuildCraft, Mystcraft, Forestry.. all leaders in the Forge modding world. But there are still factions of modders sticking with Risugami ML, or even using raw jarmod edits like Better than Wolves. Not to mention - server-only "plugin" development using Bukkit is almost a completely separate community. You have the vanilla original CraftBukkit server implementation, then performance-focused forks like Spigot, or other forks with their own goals like SportBukkit, Libigot, or the mod-compatible MCPC+.. each with their own benefits. Fortunately most have similar plugin compatibility, but a few add new APIs, or otherwise change Minecraft behavior..
Bottom line, Minecraft modding is a hodgepodge of often-incompatible rapidly-changing frameworks, built on an unstable rapidly-changing foundation (which is obfuscated and has to be reverse-engineered each release, nonetheless). There have been advancements to streamline this problem, and it is getting better, but we're not out of the woods yet. Even tutorials you can find online for modding – such as on the Minecraft Forge wiki, are frequently outdated. A book would even be more so.
Nonetheless, I think you're right, it would be very nice if someone could pull it off, putting out an informative yet updated book on Minecraft modding. Maybe things will settle down and stabilize after the infamous Mojang modding/plugin API is released.
This project is very interesting for a number of reasons, I'm surprised it hasn't received more attention. If I were Mojang I'd be quaking in my boots right now.
No single factor has been exclusively responsible for Minecraft's runaway success, but an undeniable essential contributor has been the extensive modding community which has formed around the game. The nature of the game as a sandbox makes it highly amenable to modding, and by writing it in Java -- a language easily decompiled and recompiled, for modding -- Notch (perhaps inadvertently) allowed this modding to take off, launching Minecraft into the stratosphere.
Countless clones of Minecraft have been attempted, yet none gaining any traction comparable to the original. Part is this phenomena can be chalked up to the first mover effect (though arguably Infiniminer was first), sure, but I'd argue the mod-ability of Minecraft is an even more important reason for its continued success. Mojang believes this too: jeb_, the current lead developer, has said he strongly believes a modding API is crucial for Minecraft's future, and its his #1 priority.
Seriously, if you've never played Minecraft before, the difference between "vanilla" Minecraft and Minecraft mods collectively (as in modpacks such as Feed the Beast) is like night in day. Many "mods" can be better considered as completely different games. We're not talking about minor tweaks and modifications, but brand new and compelling gameplay content.
Mojang is working very hard on cleaning up and refactoring and optimizing the code (never originally intended for modding) in preparation for an official mod API, anticipated by players and modders everywhere. But here's the kicker: what if someone else beats them to it?
For this reason, Voxel.js's focus from on developing a modular engine with plugin-able modules from day one is pure genius. Climbing over the wreckage of abandoned one-off clones, they sought to build something better, something sustainable. And it is working: even after only a month of hacking, Voxel.js already has several fairly impressive third party addons. Tree generation, solar cycles, terrain gen, multiplayer.. Not bad at all. And someone is even working on bringing in WorldEdit-ish functionality!
Yet modularity on its own is not enough. Several Minecraft clones already have plugin support, but nonetheless lack the player base of the original. In order to attract developers, modders, and players not only must the platform be architecturally attractive but accessible as well. Voxel.js fits the bill even better than Minecraft -- nothing to install, just go to a website in your browser, and begin to play. (Minecraft, as a Java app, could be played within a browser I believe, but especially with Oracle phasing out applets, I wouldn't consider it on the same level as modern JavaScript web apps).
So there you have it: the inherently attractive nature of an open world sandbox voxel game, an open and modular design built for the ground up specifically intended to be reusable, on top of the low-friction easily accessible platform of the web. As more modders begin to take note, I expect the snowball effect to kick in, and Voxel.js (or its derivatives, or its own clones!) could take off and become even bigger than Minecraft.
The why hasn't it? In fact, I attempted to develop a project a while back almost exactly like Voxel.js. JavaScript+WebGL+websockets+voxels+sandbox (an enticing combination if their is one). The technology just wasn't there at the time. The pointer lock API is mandatory for these kinds of games, and I'm pleased it has been implemented in Chrome by now (an other browsers soon) -- this demo works amazing well. Could use a little polish, but I could see myself playing this for real.
Perhaps my involvement with Minecraft modding and abundant familiarity with its limitations (as the author of this article brought up: decompiling...yeah) has led me to be overly optimistic of viable alter alernative platform. After all, Minecraft is more of a platform for games than a game in itself. There's no reason why someone couldn't build a better platform draw gamers and modders from Minecraft. Who knows, maybe Voxel.js is that platform.
Although Mojang did hire the core Bukkit team, the mod API they are working on is planned to be a new API designed from the ground up, rather than Bukkit [1]. Bukkit was designed within constraints appropriate at the time for the environment it arose in (for example, it is layered as: the Bukkit API itself, on top of the CraftBukkit server implementation, which is itself a mod on the "vanilla" Minecraft server jar from Mojang -- abstractions to help insulate Bukkit plugins from the volatile nature of Minecraft internals). They did design a fairly good API, the most successful in the Minecraft modding community no doubt, but having a new official API built into the game has a number of advantages and is their ultimate goal. Although there may be a Bukkit compatibility layer or a documentation on porting from Bukkit to the official mod API.
It isn't clear what will happen to Bukkit after the official API is released. The founder of Bukkit has said they intend to phase it out. But Bukkit is an open source project, LGPL, with many active contributors and a thriving community of plugin developers. Will be interesting to see what happens, although IMHO a proper, well-designed official Minecraft API can only be for the better.
You may be interested in the Minecraft Coder Pack from Ocean Labs - they include the Fernflower decompiler, producing very high quality output (certainly better than jad, tbh not sure how it compares with JD-GUI). But even better, MCP includes a comprehensive set of "mappings", providing informative names for each class, and most important field and method names.
Running a decompiler (JD-GUI or otherwise) on Minecraft by itself will produce obfuscated source, so having this deobfuscation step is very useful as a modder. If a symbol is not deobfuscated, you can submit a proposed name on IRC to MCPBot, or even provide a description for the Javadoc.
The end result of running MCP on Minecraft is a fairly readable source base, which one can easily make changes to and recompile. This is how modding frameworks such as FML and Minecraft Forge are built (although CraftBukkit uses a different approach - they don't use MCP but their own, less comprehensive and incompatible mappings, one reason why Forge mods and Bukkit plugins cannot easily be used together, a problem being solved with the merged Forge/Bukkit "MCPC+" server from MC Port Central).
This pattern has repeated throughout Minecraft's release cycle. Though with Minecraft 1.0 it is no longer considered in "beta", each major version has brought incompatible changes. Mojang doesn't use semantic versioning, needless to say. Had a book been written around 1.2, it would have undoubtedly focused on the singleplayer/multiplayer split, and the steps needed for modders to develop SSP-only or SMP-compatible mods, but this distinction was blurred or eliminated in 1.3. 1.3 was mostly a dead zone for modding, only to come back in 1.4. With 1.4 we saw the introduction of new server implementations or administration mods, combining either analogous functionality or proper support for both leading modding frameworks, Forge and Bukkit (including MCPC+, BukkitForge, ForgeEssentials, etc.).
Modding toolkits come and go: about a mere year ago, you might be modding with ModLoader, ModLoaderMP, AudioMod. Or pure Minecraft Coder Pack (MCP), with no APIs. Or lesser-known custom APIs. Nowadays, Forge ModLoader has basically taken over ModLoader, and many modders have been moving to Forge for compatibility and other reasons. IndustrialCraft, BuildCraft, Mystcraft, Forestry.. all leaders in the Forge modding world. But there are still factions of modders sticking with Risugami ML, or even using raw jarmod edits like Better than Wolves. Not to mention - server-only "plugin" development using Bukkit is almost a completely separate community. You have the vanilla original CraftBukkit server implementation, then performance-focused forks like Spigot, or other forks with their own goals like SportBukkit, Libigot, or the mod-compatible MCPC+.. each with their own benefits. Fortunately most have similar plugin compatibility, but a few add new APIs, or otherwise change Minecraft behavior..
Bottom line, Minecraft modding is a hodgepodge of often-incompatible rapidly-changing frameworks, built on an unstable rapidly-changing foundation (which is obfuscated and has to be reverse-engineered each release, nonetheless). There have been advancements to streamline this problem, and it is getting better, but we're not out of the woods yet. Even tutorials you can find online for modding – such as on the Minecraft Forge wiki, are frequently outdated. A book would even be more so.
Nonetheless, I think you're right, it would be very nice if someone could pull it off, putting out an informative yet updated book on Minecraft modding. Maybe things will settle down and stabilize after the infamous Mojang modding/plugin API is released.