When you're a group of fewer than 5 programmers and you're all smarter than the average bear, they're useless.
In essence, they're a ritualization of the communication and testing process that has to happen to make software good and reliable. Without some communication and testing, the software will suck; at a certain organizational size, or with programmers of lower ability levels, you can't rely on the programmers to do it themselves.
But in the end, to build software you have to communicate. Once the group working on the software is larger than 5 or 6, unless everyone on the team is phenomenally good, you need to formalize this communication somehow. All of these formal development methodologies are ways of accomplishing that -- none of them are necessarily good, but at least they solve that problem so you can get to other problems.
Of course, this leads to other problems, such as the ISO 9001 compliant company that has all of its dysfunctional processes documented in explicit detail that must be followed. (I worked there once. It was like Office Space meets Brazil.)
As for me, I don't like it. I abide by it at work and it's generally a huge bottleneck for all projects. Many of the ideas the SEI proposes are good practice, and I have a feeling a lot of developers already follow them without knowing that they're part of any "process".
A bad implementation of CMMI at an organization only makes things worse. For example, the latest version of CMMI encourages us to engage in rapid feedback cycles with customers, which is great. But the system we're supposed to track when and how we did that is clunky and consumes time, to the point that you don't want to go talk to customers for fear of having to do more writing and documenation.
So what we have here is the attempt by non-technical managers, to bring some "feel" of control over something inherently complex (software development), modeled by their semi-successful methods of management employed in traditional industries (read companies like GE).
What those guys fail to realize is that software engineering is fundamentally more complex and, therefore, unpredictable than manufacturing industry they're used to (from their business school books).
Pathetic.
Granted, there are some common sense aspects that are slam dunks (c'mon, version control, why wouldn't you use it) but a lot of it still favours serious software where all the engineers wear dark suits and ties and do big design up front.
Most startups would run out of time and money just getting to level 2 CMMi compliance before they even started to really cut any code.