I dunno. For me it is a running gag when I go to a McDonald's in a distant city, particularly in a foreign country, and say to somebody who's been waiting in line "... I thought this was supposed to be fast food".
In software development it is quite official that a fast computer is a good thing, I mean, idle minds do the devil's work if your compile takes 40 minutes.
Your compile should take a minute or so, though. And that's arguably slow.
40 min is order of magnitude slower, but the goal is not to be as slow as possible.
If you have e.g. a hot reload (instant recompile), that's fantastic, but you probably don't actually want to constantly re-configure the code, rather check on various state etc.
You also want to eventually start over as the size of the state changes outside the normal running parameters increases, and that's when you may want a slower recompile.
If it takes only a second, you probably didn't have enough code to work on, and it provides incentive to avoid frequent recompiles and stay in hot-reload. Even in languages without hot reload, this generally holds true.
You want a bit of time to consider which issues to fix, and you want some reason to try to get it right...the tradeoff is generally better code. The alternative is expensive (memory/disk/time) activities such as excessive and incorrect (re)-testing.
Put another way, fast cycle times are only better than slow ones if the quality and feature richness of your codebase is better than slow cycle times.
I would prefer to take 40 minutes and have a compiler spit out a guarantee of correctness than spend two weeks hot reloading junk.
In software development it is quite official that a fast computer is a good thing, I mean, idle minds do the devil's work if your compile takes 40 minutes.