I would say you need to stand up for your users not your product. A gorgeous code base that doesn't do what your users want doesn't help anyone.
It is important to listen to your users, but not necessarily do what your user’s want.
Especially in the context of the user’s role.
Adding a thousand requested features also has its drawbacks.
IMO a clever one-liner or a hyper optimal routine that takes minutes of staring to decode isn't gorgeous, but you're certainly right that many would disagree with that. IMHO this philosophy runs directly contradictory to the one in which leaders empower those around them.
If you stand up for your product, you are standing up for your users, or your clients if that's a less ambiguous term.
For some teams, for example a lot of teams in Google and Facebook, the end-users are often different from the Product's clients; the client of Google's Chrome is Google's empire. The programmer that added the X-Client-Data header undoubtedly improved the product, at least short-term-business-wise, while actively harming it for end-users. Someday end-users may leave if they continue to erode trust, but for now it's a boon for the Product.
Edit: Please don't work on those products. Please develop products that respect people. If you develop trust, and actively respect people; I posit that a lot of people will opt-in to reasonable analytics, and even advertising. If many don't now, they might when the dust settles.
The one caveat is to be sure to also think about your team members as "users" of the code base.
Also, I think we are going to see further evolution in the software industry where the current middle-mgmt layers get wiped out. You are either contributing directly to the product - and you can easily measure that - or, you need to get out of the way.
DevOps is a drive to reduce the number of vertical organisational ‘layers’, ProductEngineering would be a drive to reduce the number of horizontal organisational layers.
IMHO.