Proprietary solutions come with proprietary costs which force careful consideration of how a tool is used. Therefore it's not Jenkins that is the problem but that it's so open, easy, and useful that everybody wants to use it now instead of waiting for a standardized and supported deployment in a central location.
To address the concern of sprawl you noted there needs to be goverence. I'm simply saying that closed source tools have an up front and/or reoccuring cost associated with their use and therefore the tool is governed from the beginning. Yes, the value is key to tool choice, but I disagree that Jenkins is not usable for an enterprise level solution. It is more that enterprises are not well positioned to assess the non-monitary cost of using the tool in a uniform and supported way which results in sprawl. Teams are likely to find "real" build tools to be cumbersom, bloated, slow, etc and therefore create a team based solution. Because it is easy, flexible, and open but not because it isn't something that is ready for use in enterprises.
Proprietary solutions come with proprietary costs which force careful consideration of how a tool is used. Therefore it's not Jenkins that is the problem but that it's so open, easy, and useful that everybody wants to use it now instead of waiting for a standardized and supported deployment in a central location.