That's the whole point. Code is not meant to serve the people who maintain it. Maintainability is only a concern once lack of such starts impacting your actual customers. If writing ugly code and fixing it up later is necessary in order to get shit out the door, why is that bad?
So because it satisfies the suits, he should reserve passing judgement? Try again; he is a programmer, not a suit. Hint: there exist many seperate but equally valid systems for judging worth/merit/quality.
Also, even for a suit, "Maintainability is only a concern once lack of such starts impacting your actual customers." is only true if by "actual customers" you mean shareholders. If you really want to get down to it and make an obnoxious out of place point, you can technically fuck over the customers all you want so long as doing so does not actually hurt the business (meaning: hurt the shareholders). Bonus points for figuring out how this could be done by a consulting company.
If you are a money-chasing robot, perhaps. Most businesses care at least a little about making a good product/satisfying their customers. That's good. Making life easy for your employees at the expense of your customers? That's bad.
Because if you want to be a software developer in the long term, you need to prefer the long term alternative in most cases.
A typical example is, "If we don't get something out the door, we'll be out of business. 'Shit' is something that can be shipped quickly, therefore we must ship 'shit'."
But companies that ship 'shit' generally go out of business anyway. Either their customers find it unappealing and leave, or ongoing maintenance quickly becomes so difficult and expensive that the product can not improve except by being rewritten under new management.
With something like a secure website (or script injected into arbitrary websites by a large ISP) the severity of the security vulnerabilities that tend to result from "shipping shit" often you only get one or two chances as a company.