This is a really tricky one that we're still trying to address. The plugin structure was added after OJS 2.0 was released, so we had to find a way to fit plugins into the existing system in a way that wasn't disruptive. As a result, there are things that plugins can't currently do easily (though with hooks it is possible to step in and change existing parts of OJS, rather than just adding new functionality, depending on what exactly you want to accomplish).
What we hope to do to increase the flexibility of plugins is gradually move some of OJS's functionality into plugins and out of the core. This is already taking place with, for example, the OAI metadata formats, citation formats, reports, and other aspects. This will make the core smaller, and will also allow plugins to interoperate with OJS functionality as peers, rather than as grafted-on bits of code that are less capable than the core itself.
It's particularly tricky to accomplish a good plugin structure in PHP, as PHP's powers of introspection are much more limited than, say, Java. We also have to keep in mind that a lot of infrastructural development can come at a cost to performance.
In other words, it's a complicated problem with lots of trade-offs -- but we're doing what we can.
To follow your example of removing the breadcrumb menu, that would currently be a tricky removal to accomplish with a plugin. We're breaking templates up into smaller pieces to make them more modular, which will eventually address this requirement (it's possible for plugins to interact with core template files fairly easily, but not pieces within a template). In the meantime, I would suggest modifying the core template to conditionally remove the breadcrumbs.
Public Knowledge Project Team