I've lost track of the number of times I've encountered people using wildly inappropriate systems with which to build solutions. Sometimes this is because they are familiar with the system and apply it by default to everything (which I discussed in Generalists vs. Specialists). At other times this is because the system has already been purchased or is already available and there's a feeling that it's wasteful not to use it. In other circumstances it may be that because it has applicability to a subset of your problem it's been applied to the entirety of your solution without questioning it's overall utility.
 
Using an existing or already purchased system just because you have it already is applying flawed thinking to the problem. The cost to obtain the system has already been paid and it's non-recoverable. There is no business value is having your solution use the system just so you can say you've used it. End users don't care how the magic happens, just that it does. If the system imposes costs on the development of your solution that outweight its benefits the appropriate technical decision is to not use it. You may not get the cost of the system back, but you also won't be spending additional money, time and resources using something unsuitable for your problem.
 
This conveniently ignores the political dimension. People who have to justify spending money on purchasing a system are going to have a strong incentive to ensure that it gets used so they can avoid uncomfortable questions about why they spent money on something that wasn't needed. It can also be difficult to make the case to non-technical decision makers that using an existing system is the more costly option overall compared to building a new system or aquiring an alternative.

Overusing a system that does part of what you need is also relatively common. Your solution requires functionality X. System Y provides X, so you decide to employ it. This leads to a solution built around Y. This is relatively common an not in itself a bad thing provided you understand the tradeoffs, such as being tied to Y. Where the problems come in is when Y takes over your implementation. If you need to do Z but Y doesn't readily support Z you now have a large additional amount of work to do to make Z possible. This is costly and tends to lead to sub-optimal implementations of Z.
 
I've seen this a lot with various web development platforms which are what I call "control freaky". These get involved in every web request, enforcing their limitations and style on every web request. Suddenly the system you used to solve a minor part of your application is dictating terms to your entire implementation. This can get very painful very quickly.
 
The appropriate way to deal with is by appropriate partitioning of your system. Apply the system to only those parts of the solution for which it is applicable. Enforce boundaries and don't allow it to have effects across them. This naturally leads to a componentised system for which Service Oriented Architecture (SOA) is a good fit.