The problem comes later when the code no longer reveals the domain and the processes of the business, and where changes start affecting other expected business behaviors (at least that is what I think would happen, I find the code too distasteful to let it get that far).
Yes, that's partly a sense of qualified taste I've built through experience, but I think it also comes from trying to actually understand user needs better. E.g. Our finance department says they wants a daily report of invoices, but what do they ACTUALLY NEED? Maybe the problem to solve is to allow more flexibility with billing dates, or increase billing strike attempts, etc. That stuff sometimes doesn't come out until you really ask because of all sorts of organizational and social beliefs, fears, etc. Practicing that and recognizing the signs means you can do that rethinking earlier on in the process, before dev starts.