I think the point doesn't stand up to close scrutiny, but taking into consideration that the actual implementation of this action-reward feedback loop is probably more nuanced, it makes a bit more sense[^1]. Obviously, you don't want someone pumping out nothing but garbage commits and forcing it onto the production branch, but at the same time you really can't afford perfectionists who spend all their time stressing about a fractal infinity of possibilities containing other possibilities. Furthermore, in a startup environment a dev moving slowly because they're busy helping other devs can lead to the obfuscation of management issues. If a dev looks more 2X capable than they actually are because they're using up half the time of a 10X dev, then you really should be assigning the less capable dev a lighter workload where they're less likely to block things.
Bugs obviously can spiral into more time and time spent early can avoid timesinks and various issues down the line. I completely agree that spending a day to prevent an issue causing weeks to months of headaches is completely worth it (and to add to your point, I lost all respect for management when perfectly foreseeable issues weren't addressed, especially when I requested resources to address the issue). This is probably where the nuance is lost, where you need to have checks and balances in place to ensure that critical decisions are being made by the right people, and that guardrails exist so that devs can move quickly without stepping on anyone's toes.
[^1]: While Dan Luu's statement that nuance doesn't scale isn't entirely applicable, there's a similar effect here where nuance is sacrificed for a punchy, memorable aphorism. I personally don't agree with sacrificing nuance for more base appeal, but we can maybe also take for granted that readers have some capacity for critical thought (and the ones that blindly accept this advice won't hurt too many people when they inevitably fail spectacularly).