Most clients ask, at some point, why the code we hand them is not more clever. We sometimes get the question politely, in the form of "could we use the new thing"; we sometimes get it less politely, in the form of "the developer we asked says this is old-fashioned." The answer is always some version of the same thing: cleverness has a cost, the cost is paid by whoever has to read the code next, and the person reading the code next is almost never the person who wrote it.
I had a job, years ago, where I rewrote a perfectly working five-hundred-line PHP file into a tightly-typed three-hundred-line Go service that did the same thing. The Go service was, by any reasonable engineering metric, better than the PHP file. It was twice as fast, it was a third smaller, it had a real test suite. It was also impossible to debug in production because nobody else on the team wrote Go, and three years after I left, the team rewrote it back into PHP. The cleverness I had introduced was the cleverness of someone who would not be there in three years.
There is a tendency to believe that engineering rigour means using the most powerful tool for the job. It does not. Engineering rigour means using the tool that the team can still operate after three people have come and gone. For a small studio building software for clients we will eventually leave, the operating constraint is brutally clear: the code we write has to be operable by someone who is not us, on a stack they already know, using techniques they have already seen.
In practice this means we write boring code. We write the obvious nested loop instead of the clever functional reduction. We name variables fully. We write comments that explain what the code is for, not what it does. We use whatever language the client already uses unless there is a real reason to introduce a second one. We are aware that this would be embarrassing to a certain kind of senior engineer; we are also aware that the certain kind of senior engineer is not the one operating the code in two years.
There is one place where we let ourselves be clever, which is the deployment and operations layer. The build pipeline can be as complicated as it needs to be, because the build pipeline is operated by us and inherited by us. But the application code itself stays at the boring end of the dial, because the application code gets inherited by whichever junior developer the client hires in the third year. The first time you see a clever piece of code you wrote come back at you, in an email from a stranger asking what it does, you start to write boring code. After a few years you stop noticing that you used to write clever code at all.