That's assuming that comments add a significant amount time to a project. Granted, that extraneous comments are not a good thing, however the whole reason it is considered a good idea in the community, is because a comment takes 10 seconds to write for the developer. When you wrote a piece of code you know exactly what it is doing and can comment with very little effort.
You also need to consider, that it is dangerous not to have standards on when to comment. You may be very good about only commenting when appropriate, but there are many developers who put simply suck. They either write confusing code, or they just don't think too much about comments and add them almost randomly. With strict standards, you get a product that has been commented consistently, even if somewhat extraneously, which is a lot better than a lack of comments.
As an example, you can comment methods in C# describing the method and the parameters which then show up in intellisense (tooltips). You could only comment methods that are not immediately understandable from the name of the method. But then, you don't know how other people might interpret these names. So you then play it safe and do ones that could be slightly confusing. Then you have 90% of them commented and the other 10% missing, which will likely concern other developers as to why they are missing. So, it is generally not worth the tiny amount of time you save being selective with comments.
The other aspect is, I think it is excellent practice to write comments before you code. This way, you often find flaws in your logic before you write any code, thus saving time. Once it is all good, then you just fill in the blanks, in which case commenting doesn't add any time at all.
It's a big assumption to say that all future developers to look at a block of code will understand it, especially when to you as the developer who wrote it it is all obvious.
