Well .. yes .. to an extent your point of view does match my view - because I feel that when you reach a step in the workflow that is weak, it indicates a prior step that is also weak. Which is why sometimes you get to Qualification of a feature, for example, and find that it doesn't match expectations - because the Requirements didn't fulfill the conclusions of the Analysis, say. Or because, indeed, of a weak Analysis or crap Implementation.
However, there is a subtlety to this:
>So I believe that waterfall is still a good methodology, but (in most cases) only if it is done as a directed cyclic graph rather than a strict linear sequence, such that blocks of steps can be repeated.
Its both! You go through linearly, and if you're lucky, you ship! But if you don't ship, you go back to the prior weak step until it is strong enough to allow you to continue the linear path - and yes, it is always best done linearly from that point, in my opinion. Don't skip forward steps if you've done review and found a weakness, usually in Qualifications, but also very often in weak Specifications or Requirements - which always indicate a failure to properly Analyse. Instead, go back to the prior incomplete/inaccurate step, and redress the issue - and continue forward with the next step from there. No skipping! Skipping makes the whole thing weak again, polluting the stream. Rigorous linearity holds the order.
For this reason, I have added 'gatekeeper' steps to my workflow, which I didn't want to include in my original comment, because I knew someone would then say "but thats not waterfall!" .. Waterfall needs review steps - navel-gazing - imho, which is why I always include:
Analysis - Requirements - Specification - Design - [INTAKE] - Implementation - Qualification - Testing - [REVIEW] - Release.
[INTAKE] is there to protect Developer sanity. If they intake the Design and find it wanting, that is the point where they can kick it back to the team (or internally, personally) to the prior, weak missing step. Same with [REVIEW] which is there more for managers so that they have an opportunity to indicate the weak/missing steps, prior to Release ...
Without these two review steps, Developers and Managers will rip each other to pieces trying to assign blame/responsibility - but with these review steps, there is an opportunity for everyone to get along. Devs can kick things back if they feel things are weak, and nobody gets offended, because at the end of the line, prior to Release, managers can do it too ..
Note that [INTAKE] allows Developers to protect themselves from issues that will negatively impact their ability to Implement, and [REVIEW] gives Managers a means to allow other factors (market conditions, business cases, etc.) to impact Development, and respond appropriately. These tow actions, done iteratively by well-coordinated Developer/Manager roles, produce great technology.
Estimation: the more rigorous you are about the workflow, the better you get at Estimation, as a Developer and as a Manager. Also, the less rigorous you are about the linearity of the workflow, the worse your estimates - because there will be weak/missing steps which hide costs, time and energy.