How to prepare sensibly for a disclosure of nothing

If there's any lesson from Badlock, it is that it has taught us how not to disclose a security vulnerability. If you get a logo, a snazzy name, a url, a website and a marketing agency, and then ramp up the suspense for about three weeks ("Mark the date,"  "Please get yourself ready to patch all systems on this day" - courtesy wired, who wisely kept a copy of the older site), you have to deliver the goods.
SerNet surely delivered a bug and a vulnerability, but, I think, failed to properly appreciate the difficulty of the threat vector, as well as the impact of a successful exploit and hence underwhelmed in overall risk.
Let me briefly explain this. If the threat vector is 'man in the middle' and the impact is 'privilege escalation' or 'denial of service' (as opposed to the holy grail of remote code execution), then a successful exploit in many environments adds nothing new to what you've got already. If you can MITM something, you can stop it from delivering service. And also, you probably already have elevated privileges on a network or one of the endpoints. Therefore a successful exploit may only add some accounts to your arsenal, and not deliver more rights.
Should you patch? Absolutely. Should you pull out all stops to patch now? Perhaps not. At least not everywhere.
To sum up, I, like many other security professionals, am somewhat peeved at SerNet for kicking up the stink and then not delivering the goods. That may sound like masochism, as some have suggested, but these sort of goings-on can be an actual threat to security operations to the degree that they breed mistrust in the infosec profession and complacency everywhere else.
A problem for people running security teams is how to prepare for threats like this. It is easy to do a SerNet and pull out all the stops on our community, and get them ready for disaster to strike. But any failure to then deliver the goods on the day will only set the business up for complacency in an area of security that is already notoriously difficult: patching and maintenance. And it can, in one day, destroy a reputation for the security team that has taken years to build.
I am fortunate. One of my messages to the business was that I did not discount the possibility that this would turn out to be a storm in a teacup, as indeed it was. We were prepared, even for something like this.
I think there are a few lessons to learn here if you run an operational team:

1. Have discovery infrastructure for your own environment. By that I mean that you have to be ready to find out what systems are running SMB ports on your network right now. Not what is in the asset register. Not what the architects think you have. Be able to discover what you have with minimal effort, so that you can prepare with minimal effort.
2. Communicate with care. Threat inflation is not a strategy for success. It is the road to failure.
3. A Corollary: Be aware of the fact  that in the infosec profession there is a fine line between being seriously 'leet with 'attitude' and being a jerk. Always prepare for the possibility that the announcing party is a jerk. Chances of that increase if the secrecy and alarming language ramp up.
4. Recognise the signs. The serious vulnerabilities - Heartbleed as an example - were patched on the quiet first and only got the website and logo once the vulnerability was ready to be released (or very shortly before, if my memory serves). There was no three week 'ramp up the heat' time.

Of these, I think 1 and 2 are the most important to manage threats like this one.