Well, yes. But if builders is the issue only, a lot of that can be handled simply by designing for it in the first place. If I give my builders lua (I use lua here because it's well-known and fast), and a hook that lets them make custom commands for their room (really, really not a good idea in my opinion), I've solved sandboxing because you only get what I want to give you, and you don't have to reboot the server for any minor area changes. Going even further and making class spells and skills, for example, lua scripts is feasible too. Lpc is not outdated, not really, but I do think that new mudlibs should, perhaps, be new mud codebases that use modern technologies. The problems with LPC as I perceive them are above, I'm not going to repeat them here, though I will add that modern scripting languages, at least some of them, have optimizing implementations that go beyond what lpc typically does.
Using reflection to dynamically load code into the running codebase is not a good idea: sandboxing is the big one here, yes, but also most of the systems that use such techniques optimize code as it runs. Take java for example. Java can approach native speed after a few hours of running. Imbed some new code, which is actually a bit tricky, and even the machinery that would normally optimize your code starts having trouble, even before code is loaded: you're computing method names, basically, and therefore it can't make asumptions. On top of that: it's typically easy to load new code, it's typically harder to get it unloaded, typically involving wrappers wherein you implement the functionality to let go of the old code. I looked once, out of curiosity, into methods of doing this properly in java while it is running--ie without reboot--but it's been a while and the answer was always yes, but. The conclusion was that getting a new class into the system is easy, getting an old class out is hard to impossible.
There are programming languages that make this possible and somewhat easy to do, i.e. Python, but those have their own issues: even PyPy, for example, takes 40mb to hold 1 million objects with three fields; if these are objects with 3 32-bit int fields, it should only be taking half that. The default cpython is even worse. The languages that make these techniques possible have overhead, and lots of it, most of it having to do with being dynamically typed. It is possible in python to add, not to a class but an individual variable, a new method at runtime that is only valid for that variable and will not work on any others of the same class (saying same class is also misleading, to be honest), but thhat means in the default implementation, most variables start carrieing around a map of methods and their implementations.
What I think LPC provides, since I've been only negative so far: for the standpoint of new muds, not new mudlibs (codebase, as far as I'm concerned, really), you can get basic rooms and objects, and you can pretty much code anything without having to look at the javadoc, for example--it's a small enough environment not to overwhelm a newbie builder who hasn't seen code before, or for that matter a veteran programmer who has, it's specialized for strings, and it hides a lot of stuff like pointers. There's a lot of mud-specific support. It can be secured, if you know what you're doing. The power of builders isn't limited, which is both a good and a bad thing, depending on how much standards you have in place that you rigidly make everyone adhere to (see old lpmuds, and the typical example of throw rock that gets thrown around when add_action is bad comes up). It offers, for new mudlibs, preimplemented telnet, but in the grand scheme of things implementing telnet is a very, very small amount of work, anyway.
