Consider me skeptical that there will be any real improvement from this.
(I am not claiming forks are bad, only that it solves a different problem than support hell)
For example, my company is working on a huge web project for IBM right now, it is a Javascript based front end, in which we use Dojo as the toolkit. It would be safe to say that there are more lines of Javascript code than Gmail has in this project and yet our Monkey Patch files probably consist of less than 20 lines of code. It would be overkill to maintain a branch of Dojo for those 20 lines of code, especially given the fact that most of the patches are to customize Dojo to do things the way we want it too and not true bugs. So they have no hope of making it back into Dojo proper. With Monkey Patching we just maintain our own Monkey Patch files along with our code base. We just upgraded the project from 1.5 to 1.6 which if we would have been maintaining our own version, it would not have been a 30 minute process.
That being said, if a developer is Monkey Patching his own or internal code, it should serve as a red flag that they may be doing something wrong.
In said project we had a number of modifications to libraries to support some additional desired functionality. The developers at the time simply forked the library and wrote patches on top of the mainline branch. We found this significantly impeded our ability to upgrade, or take advantage of changes, down the line, as well as to track upstream's HEAD. When one forks, branches, and then patches on the branch, these problems are easily skirted. In addition, it's easy to submit your patches for integration into upstream.
In the end the gain is flexibility. One cannot discount the value of flexibility.
Out of the frying pan, into the fire
Especially if you consider that part of the problem is that something won't work but it may take hours to understand it's because the semantics of Enumerable#group_by in library X are not the same as the ones defined in library Y.