Depends on your skill level. I'm half considering paying $500 for an Ida Pro license and trying to disassemble as much of the game engine as I can figure out, just to learn about disassembling. That's also not a project I'd recommend to most people just for the learning experience, but it fits me just fine.

They have a free version of 5.0 with some reduced functionality.
Modding is great for learning on two levels: it teaches you to anolyze and understand software ecosystems, and it teaches you to be creative about working around limitations in existing systems. This project, however you approach it, has both of those in spades.
No argument there. I was specifically speaking about this team taking on this project simply for learning experience.
That does sound quite nice. I'll have to take a peek at the code myself.
I'm currently going through the IDA Book (2nd Ed.) so I can start finding all of the relevant function and data addresses. Mostly because the SKSE folks don't want to release their IDBs, which is pretty sad (they said they thought it was too much of a gray area, but IMO it's much less gray than SKSE itself). If I make any significant progress in annotating the IDB I'll definitely be releasing it.
Ain't that the truth.
A new programmer writes his own solution. An intermediate programmer can tell you about an awesome framework/language that practically solves the problem for him. A true greybeard only writes his own solution after reading the source code of existing solutions and calling the authors idiots.
Hell is other people's code.

Hah, true that. Learning huge codebases is a pain, but over the years I've personally become comfortable with it more and more, especially after extensively learning Ageia's (when I started with it, now NVIDIA's) PhysX SDK. And that is a massive and hairy SDK/API, though it does have *fairly* good docs (though some things are pretty opaque until you go in and find out your ragdoll bone orientations are completely screwed).
Edit: One final note. While I'm sure this code base is a good find and it sounds very nice, it's also the easy part of the project. I don't think it's a coincidence that the author of your code got that far and petered out.
I'm completely aware of this. However, it gets the barebones up and running fast in a pretty well written framework. I think the jumpstart will be invaluable, since a lot of the stuff Recycler wrote is the most boring stuff to write in this type of project (IMO). After it's working the hard and interesting work of making the server the authority on game state can happen.
The hard part is retooling the game engine itself and the flow of the game content to actually work as a multiplayer system. That's the part that will take months or years, if it's even possible. Even getting something as simple as conversations with NPCs to work sanely in a multiplayer context will be very hard.
Think of just the opening sequence of the game. You and whichever guy you pick, running through tunnels to escape, gates clinking shut behind you, etc. The game expects at certain points that the player is in a particular part of the cell. What if player two is still chillin one room back? How do you resolve that without potentially breaking the whole series of scripted sequences?
While I agree with you, I don't ever expect any sort of actual perfection in a mulitplayer mod. For me, it's enough if you can roughly run around and smack [censored] with a buddy over network. In the particular case of players being in different areas, I'd probably provide a spell to summon your party and/or a command to summon a specific member of your party.
Soooo much of the scripting and internal state tracking is designed to work for only one player. We're not just talking about stuff like owning the house in Whiterim. Even your unlocked dragon shouts are tracked in global variables. Whole swaths of important player information are stored not on the actor instance, but in globals.
Even if we use SKSE to add the necessary hooks to allow scripts to have awareness of a second player, we're still left with rewriting perhaps the majority of the game scripts to account for their possible presence. And that's just one aspect.
I agree that doing that would be stupid difficult. In terms of state tracked globally for the single player, I'm thinking it's possible to design a system to light-weightly replicate this to the server (everything the first time, then only things that are changed afterwards during the session) the global state for a remote client.
I don't think rewriting game scripts for multiplayer presence is even necessary, at least in the immediate future of such a project. Perhaps long-term, yeah, but for now getting a barebones network layer to work on is IMO the best way to go. I'm going to be working on getting all the necessary stuff for the VaultMP port ready for when SKSE is mature enough to work with it (I haven't really investigated whether SKSE has the stuff it needs for VaultMP's Script Extender plugin) or when I'm ready to start testing it if SKSE does already have what's needed.