In fact, companies that do this are probably more successful than not.
Your customers are your source of revenue, 'what they want' is good for your business :)
In the early stages of a company, before mass market adoption, it makes sense for companies to please whoever they can before 'lift off' into broader adoption.
So many companies got their start this way. Microsoft, Oracle etc..
From an architectural standpoint, it may sometimes seem 'impure' but then you really do have to ask yourself what you are building and why :).
What you perceive as 'cosmetic' might be some really minor thing ... but it may be absolutely critical to your customers operational needs. Remember if you have zero IT ability than the smallest process change can be a huge pain.
Example: Customer Service may be a great chance for customers to give a heads up about things that are broken or needed features. CS Reps might hear about it all the time. But they have no way to log that information, or for it to be refined. Product leaders therefore are screwed: there most important feedback is lost.
With a small change to CSR, staffers can make note of things, put priorities, now if there is a 'blow up' in a release, product can know about it right away.
Very small change can mean big impact.
The application is now so huge, that rather than reuse code, team members just add new but very similar methods for new features, because you can no longer identify the code you should be reusing/tweaking for that new feature, because it's lost in a sea of shit code and complexity, maintained by multiple developers (some good, some bad, some awful) over the last ten years.
Closely tied to Customer Driven Development, where be features get developed because customers are willing to pay for the development, even if the change doesn't make much sense, or is being used to mimic a bad manual customer business process.