This is fine optimizations for critical real-time application
But we should not sacrifice Code readability, or upgrade easiness, and global project accessibility for performance improvements on DOL except in some critical area...
If DOL needed performance critical code quality it wouldn't use Managed Framework to begin with, the flexibility of C# and the .NET framework are needed to reduce work from community and allow for wide improvements even by people who lacks development knowledge.
If you look at GameTimer Class that tries to mimic some "Assembly" low-level optimization on timer scheduling you'll see that mostly no-one can change anything in there without understanding the "high-level" algorithm.
The same goes for GameObject allocation in Region/Zone, which is really hard to read and doesn't even implement full-fledged "known" Geometry Algorithms (Nearest Neighbor with Binary Tree)
But the fact that these two aspects of DOL are intensively used in most part of the Server make them "Critical Code Area" that allows high performance gain for some "unreadable" Code...
Other Area like Game Rules, or World Events don't need such optimizations, and should be as simple and readable as possible to allow for easy customization and understanding code trace when Players encounter weird behavior in-Game.
There are lot of optimizations that can be used to improve DOL, the most obvious one are around "Collections", Boxing Collections like ArrayList or HybridDictionary should be avoided, these are always meant to hold some amount of data that could greatly take advantage of better Generic Collections like List<T> or Dictionary<K, V>, Other Collections that aren't meant to be modified should be handled as Array (Cast as ICollection<T> for overrides) avoiding using List<T> which has a big overhead...
But even this kind of optimizations sometimes bring code complexity : "Lists" have a lot of useful tools even when they are not meant to be modified (Searching Methods, Subset extracting, etc), "Arrays" lack these methods even if LINQ library can do the trick (but I'm not sure every contributor is comfortable with LINQ...), and building a "List" to finally return with ToArray() is unproductive !
I would prefer that most DOL code "obey" Object-Oriented Logic, not trying to handle Special Case in Objects that aren't meant to do this work, GamePlayer Class being over 10 000 Line is something pretty bad for example, last time I found some special Spell Method in GamePlayer Casting Area that should be in "SpellHandler" Class, other Example in SpellHandler AoE targeting we have code populating GameNPC Brain AggroTable that shouldn't be handled here !
Object-Oriented is meant to Allow group of Developers to work on different parts of a Project without breaking each other patch, this would allow easier DOL improvements, aside from performance improvements...