I have a break now...
$pref = Preference::newInstance();
$pref2 = new Preference();
What would be the use of creating another Preference object when the existent already contains all data?
And if really needed, you could just clone the current one.
Preference::newInstance()->listAll();
This is a DAO (mother class of Preference) method used by a lot of DAO subclasses, and again I don't see the point of using it.
Preference::newInstance()->findBySection('my_section');
Ok, you need to query the DB to obtain just the whole set of preferences of your plugin. When do you need that? On plugin configuration by Admin, once in while. No real saving here.
But talking about Preferences, here's a thought: Why are they all loaded at once at all? Vanilla "osclass" section, that makes sense, but why do I need 80000+ characters in a badwords list for SpamKiller plugin in homepage, search page, etc? Even item post/edit form pages don't require that, they are needed only in their aftermath and only there. That's more than a half of the total size of my Preferences,
so I'd rather save those 80-100K retrieved from the database each time any page is requested.
Anyway, all this is peanuts, your remark about indiscriminate loading of most of the classes on oc-load, that's the key. We don't need phpmailer until a mail is about to be sent, nor Admin related ones if it's a common user who is browsing, and so on.
Also, it would help a more selective loading of plugins. What use has, for instance, your brand new Benchmark plugin to the common user to be loaded every time he/she request a page?
Indeed there is much to cut here yet, we keep praying and hope the gods hear us some day.
Regards