[Kylotan]

For me the issue is maintenance. If you just want to run a Diku, fine. But as soon as you want to change something, you have to start getting your hands dirty. And the language you're using dictates just how dirty they're going to get. At some point, the linear cost of dealing with C code written in an inconsistent style over 20 years will exceed the constant cost of writing from scratch added onto the smaller linear cost of dealing with a MUD written in a higher-level language. I believe that point comes quite soon in the maintenance lifetime of a MUD (especially given that coders have always been hard to come by).

I'm not seriously arguing that everybody should be coding from scratch, just that it should be considered because it's not actually all that hard. I had basically 2 concerns which you quoted to begin with:
The 'sake of having them in Python' is for maintainability and extensibility. That's why more and more game developers are embedding Python (or Lua, or whatever) into the apps. They don't need to, but they do, because it's simply better for the task. And over time what does actually happen is that code that used to be C code is replaced by Python code. It's a slow translation, but a translation nonetheless. Most of us don't want to be fiddling with typedef structs and #macros and the like forever so we gradually change our software to something that makes life easier.

Your examples are all well and good but it's easy to come up with unusual or uncommon requirements if you're making something for vanity purposes. It doesn't change the underlying fact that a language such as Python is intrinsically better suited for networked text games.

Far easier in Python than C, really. (I wonder how many besides you and I remember the 16k mud competition...)