One viewpoint that I think is relevant here is to consider ...

• Okay, you did not write this code. You're going to have to “ramp up” on it. Now, implement this extensive but wholly-cosmetic change. By tomorrow.

When you are given that sort of task, it really drives home the nature of the coupling that necessarily must exist (somewhere, and at some level) between the presentation and the underlying data. What may appear to be “elegant” might turn out to be unmanageable, and if that is the case we have created an unnecessary problem for ourselves.

The person who is presented with this challenge is actually faced with three familiar challenges:

1. Figuring out what the existing code does.
2. Devising and executing changes to the code, to make it meet the new requirements.
3. Testing the new code to make sure that it fulfills all of the new requirements but did not regress.

If unwanted “coupling” has been introduced for any reason – “elegance” or otherwise – then we have created a very serious problem for ourselves. The amount of real-estate that our programmer must consider, must change, and must be careful not to break, could be extensive. If he or she is forced to make corresponding changes in two or more files at the same time, the probability of error is substantially increased.

Knowing this, if it were my project to architect and/or to manage, I would press very, very hard upon this topic. In fact, I might “spring” a request just like this one upon the team ... entirely without warning ... (yeah, I'm one of those) >:-D ... to actually convince myself that the strategy is not going to collapse into unmaintainability. Mind you, I'm not saying that it de facto would collapse, but I'd be pressing hard for a solid demonstration that my gut-feelings on the matter were unfounded.