Right, and you can do structured programming in assembly. But when the language or tools don't help you do that, there are examples like the one the author points out where developers don't.
Don't mistake utility (what can be done) for usability (what is easy to do). Usability always matters.
> First of all, put a comment at the top of your function that says what to expect about the return value.
I want a language that gives me a nice pleasant syntax for doing that.
> Secondly, every time you write the word "return", look up at the top of your function and make sure you are in accordance with what you said the function would do.
As a programmer, you should be trained that when you see "every time", you think "automate this". If you and everyone on your team and everyone who has ever been on your team has to remember to do something every single time, your code will accumulate a pile of instances of forgetting.
Fixing that is exactly what tools and languages are for. It's a hell of a lot easier to make a disciplined tool than a more disciplined programmer. (And when you have made a more disciplined programmer, they typically evidence that by asking for more disciplined tools.)