Some day your code will also fall under the same scrutiny, if you're (un)lucky enough to have it survive that long, by somebody who will most probably not be you. Will that person share your beliefs and definition of maintainable code? I doubt it.

At last. Realism from someone who has obviously been there, instead of book-learnt theoretic evangelism or purist dogma.

Knowing enough to not put aspirations above requirements, does not mean you disregard maintainability. It means you achieve the best possible compromise between that aspiration and the hard requirements. If the requirements can be met with best possible maintainability, there is no conflict, but when there is, the requirement comes first. S'not rocket science.