While fun to look at and calculate, it also doesn't mean a lot for most applications. I would argue that data fetching from DBs or caches will be the majority of execution time.
People keep saying that, and I would like to see some numbers for that also.
The DB dataset could be already cached in memory, for example.
But that pales in comparison to the overhead of a Database call, or even a call to Redis or Memcached.
I've read (from sources I trust) that a database call on a modern stack like .Net or JVM is 4 orders of magnitude slower than a local method call. Think about that. So if the time you spend brushing your teeth is a local method call, the entire next day is a database query.
I can't remember the source here but the information is available with a few minutes of coding or googling.
And to the caching point -- having data cached locally in memory is great, but you can't trust that.
You can if you design around handling a possibly-stale cache.
Are you disputing the premise or just disagreeing for the sake of it?
That doesn't prevent anyone from coding stuff that requires 20 times less application servers while using the same amount of database (+caching) servers.
The very idea that because the DB call takes a while to complete, we can waste even more CPU cycles is a complete misunderstanding of real world use cases.
But then, the very use of PHP means that you don't give a shit about execution time or server costs at all.