Being sloppy and being fast are not the same thing.

One can be fast by limiting complexity, yet provide a disciplined implementation.

In an uncertain scenario, such as you described, I would say it never pays to be sloppy, but it often pays not to do anything more than is absolutely necessary for the time being.

Ah the million dollar statement. Ofc you can make something completely right, that ”race car” project but then someone says “but I want a bus” and you transform it as fast as possible to a bus and somewhere half way through someone comes along and say “why isn’t it flying”.

I've never worked anywhere in 18 years where the goals of a project weren't at least limited to the correct 'vehicle class'. Implementation details sure can change but that's why "fast and disciplined" is good - you learn to implement the software in a manner where you understand the changes needed based on concrete principles rather than a mad dash of copy-and-pasting.

By 'disciplined' I don't mean that the program fullfills the dogmatic mandates of some system development philosophy - just that the software is written on solid principles that at least the author understands.

Just being curios, have you been working on the same platforms/systems during all these 18 years?

Both what you are pointing out and what the other commenter are pointing out are critical, contrasting failure modes that must be continually avoided. You both are correct.

The balance between the two will depend enormously on the circumstances, and is difficult to manage.