A short answer would be, why not?
A more detailed answer would be:
Many people have only access to computers with windows machines, myself included (until recently). There was a dearth of mud servers on the Win32 platform. That's not the case anymore. I have looked several code bases, those were not too easy to modify and had sparce documentation.
I realized that Visual Basic was readily available, and for the most part a programmer with good coding habits can make some fairly self-describing source code. This is of course also possible with other languages, but my experience has been that it's more prevalent after you have had to maintain somebody else's sloppy and undocumented code.
Visual Basic 6 is advanced enough now to do OO programming. It does not have a complete implementation yet. It still needs inheritance. I miss having inheritance, but that is solved with VB.Net. I develop enterprise middleware, ocx components, and many other objects at my day work. So I know VB's capabilities.
For those that are already thinking "Why in the heck would he/they want to code a MUD in VB?" I say that VB is just a tool, nothing else, nothing more. It is just another tool in my programming toolbox. Each tool has it's strengths and weaknesses. You just need to understand where it needs to be used at. For example, I would never dream of using VB to build device drivers. That's a domain for C++ and Assambler. Personally, I prefer Delphi to any other tool. I have run tests on different data structures and found that linked lists and hashtables vb classes, are faster than collections, dictionaries, and recordsets (which were all compiled C++ code). Again I will reiterate, It's how the tool is used and not the tool per se.
VB was chosen because:
1) This is an open source project, and the type of people that get attracted to this specific project (MUDs & newbies) tend to gravitate towards VB. In the long run, there are more VB programmers in this sector/space, which translates into possible better longevity of the project due to the amount of people (economies of scale).
2) We are not really interested in having the fastest, most tightly optimized code around, although that would be nice. We just want something that works, and is easy to maintain.