See what the other guys say and if they agree/disagree with my comments. I'm sure there'll be a bit of discussion
This 'other guy' agrees.

One point I want to push is that while as Russell states "sometimes when we're running out of clock cycles we need to make shortcuts" the point is that you can not do so without catastrophic results, if the initial code had shortcuts.

I would say that, at most, I end up with a shortcut in one of ten projects.
Often when you think you need a shortcut, you do not. For instance, in one case I had to switch a macro to a function for space reasons. This made a process too slow. I might have handled this by making the code unintelligble by changing an array to discrete entries, some in DATA, some in IDATA, some in XDATA. This would, of course have required a 'piece of true code spaghetti' to load the array. Instead of the 'shortcut' I rewrote the function in assembler and all was good.

Now, the real issue: Most of us that have been around for a while have had some code we wrote years earlier dumped on our desk with a "we need to add ...". THAT is when you learn the value of clear, understandable code. In the early days when source was processed at 10 cps and a 30 character comment added 6 seconds (two passes) to the assembly time (had this been today I would have added ~1000 such comments) I wrote code very sparsely commented. This code was given to me 3 years later to add a feature and - oh boy. I think I spent more time figuring out what was going on than I saved in the creation of the original code for 'fast assembly' (about 3 hours for the program).

Yes, with assembly times like that (and you had to sit there to make sure the paper tape did not get tangled) I MAY have had an excuse for sparse comments, but were I to do it again, even under such circumstances, I would comment with no regard for assembly time.

what makes clear, understandable code ?
1) STRUCTURE, code that run all over the place is impossible to follow
2) FUNCTION/SUBROUTINE HEADERS, every function shall have a header that states what the function does, which inputs (and their limits) the function expect and what it returns.
3) COMMENTS that state what YOU are doing, not what the instruction is doing.

The 1) 2) 3) above does not reflect priority, ALL are extremely important.

Erik