it's important not to lose sight of the ultimate goal: to get the machine to do what we want with the least amount of total human attention throughout the entire lifetime of the software.

it's a typical trap for good/idealist programmers to spend too much time on code that should already have been re-written, or not even written to begin with (because faster iteration can help refining the model/understanding, which in turn may lead to abandoning bad paths whose implementation should never have been refined to a better quality implementation).

i think it's a more important principle to always mark kludges and punts in the code and the design.

IOW sloppiness is allowed, but only when it's explicitly marked formally in code, and when not possible, then informally in comments and docs.

but then this entire discussion highly depends on the problem domain (e.g. on the cost of the various failures, etc).