This is the initial state. Many developers start with their code in this state and never move beyond it. All files are loaded all the time.
The code is always there so you don't have to worry about making sure a file is required before attempting to use it
This approach works for static functions or object oriented programing methods equally well
Files can be abstracted or condensed so it doesn't require any particular planning
It will 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 has high potential for conflict. This is especially true with JS and CSS because those files are always being loaded
It can make refactoring more difficult
It can become extremely difficult to test, especially as it grows into an unmanageable pile of spaghetti
Each file that could be simplified and many methods that can be loaded less often include the WCDC_Advanced_Hooks object which will output HTML comments in the page footer. This is to help demonstrate how weighty the plugin can become. Notice how thousands and thousands (about 9,000 to be specific) of comments are output on every single page load.
Also notice how any page using the p.description class is having the styles overridden to match the plugin style.
Finally, and most noticeably, note that every single admin page triggers the admin.js and post-meta.js alert messages. In real life this isn't something a plugin would do, but it serves to show just how annoying it is to load scripts on every single admin page when they aren't needed.