As opposed to whoever inherits the hand-rolled codebase, who will get to discover (after spending three months deciphering the architecture) that the system is buggy and riddled with totally-unique security vulnerabilities because the original author was a fallible human being. YUUUUUGE improvement.
Amazingly, yes, it is an improvement. Having the code all in one place and not spread across a dozen different frameworks makes it tremendously easier to figure out how all of the parts are fitting together.
It's the difference between having to figure out a few thousand lines of code written by a small team vs. having to parse through a million lines of code written by several different teams, some of which you don't even have because they only distribute the binary module and of course you don't have a support contract (if they are even still around). If they had a support contract they wouldn't be calling you.
The one big thing you lose however is StackOverflow. Usually bugs in frameworks have bitten people before and they'll have posted solutions online. This can be a big help, unless your client has a particularly unusual set of modules installed that are exposing some new and exciting bug.
This is why I always groan when I see a "solution" that involves bolting together dozens of different libraries (all out of date because updating any one would break the rest of the system) I know I'm in for a long day.
Using libraries is certainly a good thing and saves lots of time and effort in the long run, but they take more thought than most people are willing to put in. There are no shortcuts if you want to keep your company out of the newspaper as the next big data leak.
Wordpress is an excellent example. Even if you have the basic system down and have the management handled (either in house or externally), there's a dizzying array of interactions with the plugins that can shoot your foot right off. And don't think the Wordpress developers thought of all of the edge cases for you, they have their hands full on the main platform:
http://www.cvedetails.com/vulnerability-list/vendor_id-2337/...
At the very least you need to know enough about any solution to deploy to turn off all of the features you didn't configure/don't understand/don't need. So many vulnerabilities these days happen in features you didn't even know you had.
I know the popular saying is to never write code that you don't have to, but IMHO it's less of an evil to write your own couple of hundred lines of glue than to pull in a 100MB package that depends on a dozen other packages just to get that one mandatory piece of functionality.
Most code rot comes not from the code itself going out of date, but from its interactions with external dependencies. Managing the number of dependencies makes maintenance easier in the long run. There's nothing worse than a mandatory security update for a module that breaks another external module that is no longer maintained upstream.