You're right, when developing a product, the goal is to deliver the product and value, however a programmer who likes their job doesn't develop products all the time, they also improve themselves.

What I found is, studying "The Machine" and its details, and trying to write exceptional code, improves the "daily, mundane" code, too. Because you know what to do, and how to do it better.

In other words, if Demoscene is F1 racing, and you have the chops to design vehicles which can compete there, the technology you develop trickles down to your road-going designs, and improve them, too.

While I was writing my Ph.D. code, knowing the peculiarities of the machine allowed me to write very efficient and fast code in the first go, and the code can saturate the machine it's running on extremely well. To put in context, I was able to evaluate 1.7 million adaptive Gaussian integrations per second, per (3rd generation Intel i7) core. That code scales almost linearly until memory controller chokes because of the traffic (incidentally this happens after I saturate all the cores).

This code has no special optimizations. A single, naive, multithreaded implementation which I spent half a day designing it, that's all. There are all kinds of optimizations I can do to speed this a bit further, but since it's fast enough, I didn't bother.

At the end of the day, I'm an HPC sysadmin and developer. I inhale hardware and exhale performance. While there's a value to be delivered, it's extreme speed in my case. Because that speed saves days in research time, not milliseconds.

A rubbish hammer may be e.g. «useful» for some dozen bangs in a few weeks, then crumble. A rubbish item will have compromises. A "good" product will be masterful and optimal for function, less compromising for the demanding user.