Reality check: Gavin wrote to me only days after the BitCoinJ release to tell me how happy he was to see an alternative implementation. Satoshi expressed very similar sentiments. Nobody is against alternative implementations.
Good, it may just be that the core developers are busy (as you pointed out) now when Bitcoin has taken public interest.
What some people, especially Satoshi, have said is that there's an unusual amount of risk involved with reimplementing the full system and using that reimplementation to mine. Bitcoin is very complex and if you aren't skilled and very thorough you are likely to diverge from its behavior in small, hard to detect ways. This can fork the chain and split the economy. It's one of the few things that could instantly kill Bitcoin beyond legal harassment of its users.
Isn't this why we need client diversity? Bad blocks will not be accepted by other clients, having 1/3 of client A, 1/3 of client B and 1/3 of client C will guarantee that no one client will fork the chain. As it stands now the whole chain may have been hashed faulty.
Anyone who isn't completely fluent in C++ and the cryptography Satoshi used should think twice before deciding to write a new implementation. It's a huge amount of difficult work. BitCoinJ targets the simpler, less risky SPV/client-mode profile for this reason: bugs in it only will impact the user of that app and not the entire network because it can't mine. Even so, it's a large effort.
I assume you mean that the C++ knowledge is needed in order to understand the current client, right? If so, I hardly think that you need complete fluency in C++ as the client (the parts I've looked on) doesn't really use many of the advantages of C++. Sure, it has boost but that is about it. For the record, I have only reviewed the network and IRC code - might be some C++ voodoo elsewhere I assume. Anyhow, I think you are overestimating the difficulty of the task.
My general opinion is that if the thought of reimplementing Bitcoin from scratch doesn't make you take a deep breath, then you don't understand the system well enough to do it.
Of course it is a deep breath! It's huge - I think this can be concluded from all the stalled alternative clients (A bunch of libbitcoins, bitcoin-alt, pybitcoin). Implementing basic client support would be the first step - hashing and other stuff would be step two obviously.
As to the version number, this is a pretty trivial thing. Does anyone serious about re-implementations actually care about it? The protocol is backwards compatible to the first version, so the number only identifies which set of features the other side supports. There are service flags for the case where you want to express optional features independent of protocol version.
For me it may be a more ideological standpoint that if the developers do not want to merge such a trivial change that will greatly enhance the community by the looks of the discussions - then they do not appear to want 3:rd party developers. The protocol is the heart of a P2P - can you blame people for wanting it somewhat fixed?
If I were to create a client the last week, I would probably have announced it as "protocol version 32100". This week it is "32200" but as far as I can tell no changes. In my eyes, it just seems stupid.
Better protocol documentation would be great and I encourage people to write some (I've done my part with the articles on alt chains and contracts). All the core devs are busy right now with other things so, you'll have to dive in yourself.
The wiki has some nice discussions on the Talk page. There is a number of concerns how the fields are used and such, but it is hard to get a consensus on how it "is supposed to be". I would love to have a "bitcoin-protocol" mailing list that such issues could be discussed - but AFAIK the development team does not seem too excited about mailing lists.