DGD was designed from the start to make as few assumptions as possible. The traditional design for an LPmud-derived server involves having programmers write their code in LPC and manipulate objects in an on-line filesystem. However, nothing forces this particular structure. LPMOO is an example of a design in which the entire LPC interface is hidden from programmers. Instead, LPC is generated automatically from MOO code.
To its credit, MOO is slowly evolving to avoid many of the assumptions it currently makes. LPMOO isn't intended to replace all existing MOO servers; it is primarily presented as an example of the flexibility of DGD, and will hopefully inspire future designs for on-line interactive environments.
With all these advantages, there are still disadvantages. LPMOO is not quite as fast as the pure-C, optimized LambdaMOO. DGD is fast, but the simulation adds some overhead. The speed difference is difficult to measure quantitatively. However, the performance of LPMOO is generally quite acceptable, especially if also measured in terms of efficient memory usage. The speed issue is greatly helped by DGD's ability to "precompile" LPC into C (to link directly into the server executable itself), giving what would otherwise be interpreted execution optimal performance.