It really depends on the developer and how they’ve been trained to use WordPress. In general, I’ve seen two schools of thought:

Organic

Some developers find a feature in a plugin that they think is really cool. Unfortunately, they aren’t quite sure how to implement it on their own but really want to include the functionality in their theme. Rather than reinvent the wheel, they’ll include a drop-in plugin in their theme and go with it.

In the majority of cases (not all, but most that I’ve seen), this is a direct consequence of inexperience in a developer’s background. Either they don’t know enough PHP to build a new system on their own, or they’re too lazy to attempt it.

Product of Design

Other developers will try to cater to clients who don’t know any better. Their theme is built around, say, a large, Flash-based rotating banner plugin. The plugin is fairly well-known, but they have no idea if/when the original author will update the system with code their theme won’t understand. Changing DB schema, changing parameters, new hooks … all of these can break a theme that doesn’t update accordingly.

Rather than risk the client clicking on “update” without knowing what it will do (or risk binding themselves to an infinite string of updates for a client once the theme is done), they’ll take a snapshot of the current working version and hard-code it into the theme. That way they’ll know for sure that it will always work with their theme.

Kind of like hard-coding an external reference in Svn and then disabling version control so you can’t update it 🙂

Why it doesn’t matter

Whether the practice arose organically or intentionally, it is still a very bad idea!!!

Whether the theme updates or not, whether the plugin updates or not … WordPress will eventually update. Limiting your client to a single version is, frankly, insulting and bad business. Instead of hard-coding a drop-in plugin, just make your theme play nice with provided hooks and encourage users to install the other system. If you’re using WordPress hooks (actions and filters) rather than direct function calls, you aren’t risking much in terms of stability. If a hook changes, the feature is just disabled as if the plugin weren’t installed.