Bcrypt isn't broken or even weakened.
HMAC-MD5 isn't broken.
HMAC-MD5 and bcrypt are unrelated.
Nobody is ignoring the problem of MD5; in fact, suspicion about MD5 animates the very first secure SSL specification we have, from almost 20 years ago. Nobody is saying "just use HMAC-MD5".
They instead should learn that Y is also potentially broken in a given circumstance - and maybe that doesn't apply to my current situation but I need a review process to check that it still doesn't apply to me at a given time in the future.
For someone designing a cryptography application, this understanding should be very deep. I don't think it needs to be as deep for someone who is configuring their Apache server and just needs to know what ciphers to enable and which ones to prefer. In this case it is best to follow an industry best practice based on the type of data being sent over the wire and the compatibility/performance required by the clients/users. Then schedule an annual or quarterly review of those choices to make sure they don't go out of date and keep an eye on security bulletins in case one of them is severely broken.
The author took the opposite lesson from TLS than the one that it actually demonstrates, and the commenter above is harping on that broken lesson.
Thank you for your replies tptacek, I've learned much from this discussion. If I could edit my top comment, I would.
One particular case I remember was use of md5(md5(md5(unix_timestamp()))) to generate "secure" session tokens.