It's easy(ish) to create a first release of a product that is lean and efficient and has well-organized code.
Then you start addressing all the edge cases that it turns out you really want to handle but weren't, and adding various features that you realize really are important (that the original 'competitor' may have had some version of already too)...
Pretty soon you realize that keeping your software lean and efficient and well-organized is _hard_, the reason the original competitor was bloated and a mess was _not_ that their developers aren't as smart as yours. It's cause it's way harder to do this with living evolving software past the 1.0 release.
Doesn't mean it's impossible to keep post-1.0, mature, feature-complete software lean and efficient and well-organized. It's just hard. And will slow down your new-feature release cycle.
This cautionary note can apply to just about any "Why is X so bloated and/or such a mess internally or in it's API's, can't we write a new one without those problems?" Popular X's might include "Rails", or an existing programming language in favor of a new hot programming language.
Now, the experience of the first one that "went wrong" might be useful in creating a second one that does better -- but for it to be so, you actually have to _understand_ the experience of the first one, why various decisions were made at various times that led to "the mess". Not just assume it's because you've got smarter devs than them. And in many cases, might require making some fundamental different decisions about scope, architecture, or other goals, than the first one did -- and sticking to them.
This is related to, and kind of a generalization of, the famous Joel "rewriting software is a mistake" argument, but shouldn't be oversimplified to "never bother trying to create new software that's better than software already out there", of course.