I'm not aware of Xen being particularly susceptible to security vulnerabilities. Any software you have on your box could end up being compromised. I'm not sure why it's less urgent if you have your own hardware. And of course the other downside is that while you set maintenance windows, you also have to do all the maintenance. Not that owning your own hardware isn't something worth consider, just not sure that's the most compelling argument.
There are many pros and cons to EC2 vs managed hosting vs operating it yourself.
I meant that in this particular case, you are likely to have fewer headaches from this issue in your own datacenter because:
1. You probably don't run Xen in the first place.
2. If you do, this vulnerability may not be critical to you. I'm guessing that it is exploitable via the other instances on a host. If you don't share hardware with other companies, then a co-tenancy exploit may not be a huge deal.
3. And if the vulnerability is critical to you, you may be able to better schedule the maintenance for your own particular business needs. Fix half your hosts, fail over, fix the other half; schedule it during your particular low traffic period.
The scope of the issue is also smaller, you just have to solve the problem for your use cases rather than the massive undertaking this is for Amazon.
I don't think this one incident means EC2 is bad and real hardware is good, forever and ever. There are tradeoffs to everything.
Apples to oranges if you're comparing bare-metal to xen/ec2.
If you're just worried about being able to manage your own window you won't have access to a embargoed xen issue before it becomes public. It's the first time they forced a 2 day scheduled event on me, I'll error on the side of caution and take my reboot.
More to the point, by operating your own systems, the maintenance window is set by your staff and not Amazon.