Generally this is the first efficiency improvement developers learn. If a file is needed for the admin part of the site is_admin() is used to control and load those files verses files that are loaded on all pages and files that are loaded only on the front end of the site. Depending on the plugin, this can have big improvements in efficiency over loading all the files all the time.
It is an easy improvement to implement and can make a big difference, potentially 50% or better reduction in files loaded from the plugin on any given page load.
It will still become a fat, bloated pig. The plugin may be a simple tool but if it grows at all then the code will grow which makes it big and slow
It still has high potential for conflict. This is especially true with JS and CSS because those files are always being loaded
It can still make refactoring more difficult
It can still become extremely difficult to test, especially as it grows into an unmanageable pile of spaghetti
It gives a false sense of confidence in the efficiency of the code
Compared to the 0.1 Least Efficient plugin the number of HTML comments generated by the WCDC_Advanced_Hooks objects are reduced. On a given page load in the dashboard you will see a reduction of 1,000 HTML comments. The front end gets an even bigger reduction down to 5000 HTML comments, which is nearly half. For some plugins this simple change could make a huge difference in the amount of code loaded on any given page, which means big improvements in efficiency.
However, notice how any page using the p.description class is still having the styles overridden to match the plugin style because the admin.css file is still being loaded on every page of the dashboard.
Also note that every single admin page still triggers the admin.js and post-meta.js alert messages.
This means there is a huge potential for plugin conflict and extremely inefficient loading of scripts and styles.