What that kind of people need to understand is that "code is a liability, not an asset". Every piece of adhoc code is added maintenance cost, hence the less code the better, no matter the programming language or paradigm.
Analogously, code is cost, infra is cost, only our sold product is revenue.
A thing I did not understand for a long time is the effect this has on value. Something that produces a low value over a long time may well have been value-negative over the period because of the hidden carrying cost.
Also there may be a balance between "some hierarchy in the code so it can evolve" and adhoc code that just works for the current problem. Only having to write a new class for a new feature because everything else is handed smoothly is a bliss.
For example I could write a massive list comprehension in Python in one line that could solve my problem, but it would be much more difficult to read and would be a pain to modify. I'd much rather work with the 10 lines of code it would take to actually spell it out.
There are some other aspects to this idea of code economy: correctness and reusability. This definitely depends on the programming language.
In Java(or oop for that matter) you can get correctness but to get reusability you need a whole hierarchy of classes, lots of added code/cost.
In Python you get more reusability out of the box but to get correctness you need to add swaths of unit tests, lots of cost.
In contrast with a functional language such as Haskell you get both with less effort, fp plus a rich type system reduce code enourmosly.
I wish Rust would have gone with an ML syntax though, in particular the Hindley-Milner type signatures allow me to reason better about code reusability, the "fn" and braces just adds noise to me, too much Haskell I guess.