I just find it interesting that the efficacy of regular expressions can be framed as a computer science question, a practical question, and a statistical question.
A knee-jerk reaction to 'HTML' and 'regular expression' being used in the same sentence is like someone seeing 'goto' without understanding the context and shouting "goto considered harmful!"
I recently use some combination of perl's split() and regexes to trivially pull all links from a piece of markup. I had to suppress the "Don't parse HTML with regular expressions!" voices echoing in my head the whole time I was writing it. I'm OK with the code now, of course.
Using xpath (or just about anything else) would be smashing.
The likelihood of the markup changing to the point where the code breaks is unlikely, the target pages are open source mirrors exposed over HTTP. It even winds up being nicer code than the FTP handler.
"Don't parse HTML with regex" is good general advice, but no more an absolute than avoiding goto statements.
Or something as simple as "break 2;"
If you need to collect a number of links from the web using a spider, and you don't really mind if you get them all or not, then regex is perfectly fine. You could do a regex to match the first href="" following "<a" and stopping when it hits a "/>". This will give you at least 75% of the links on the internet, and it's done it in far less processing power or ram usage as a full html parser.
As always, a chainsaw is not necessarily better than a butter knife for cutting down trees, if the 'tree' in question is just a 5cm shoot. In fact, using a chainsaw for that would be mighty funny.
Which is why I often recommend "parsing" HTML with a regex. Particularly on throwaway projects. The overhead of a real parser is a waste.
And if the complexity grows - the sucker will need a rewrite anyhow.