The answer is, as with most anything in the filtering world, maybe, if...
By default a modern application-layer firewall (filtering proxy, etc) won't look at the SANs on the TLS certificate. That takes a decent extra punch to the available resources for something that isn't always accurate. Most systems use the host headers (for web pages), or various other indicators depending on the application being used (streaming host for rtsp, IP addresses for straight TCP, etc).
Heck, most systems don't even break into the TLS certificates because SSL inspections are costly (in resources) and cause certificate errors to appear in the end client (unless they are re-signing with an explicitly trusted internal certificate, in which case wow, that is a lot of security killing and privacy bashing mixed into one fun-sized package). That isn't to say that no one does it. I've worked on security devices for places that required an SSBI before I could know what brand equipment they used, those guys didn't care that employees might feel intruded upon if their personal email account warned about being on an untrusted connection (the employees were warned up front that all network traffic was fully monitored and recorded, for required security reasons). The other people notorious for this are public schools (I mean in the kinder thru secondary school
[K-12] type, not universities). Most jurisdictions have laws in place to protect minor children from the fact that the internet is dark and full of terrors, and several of these require that best efforts be made to guarantee that whatever a kiddo accesses is checked for bad-thing-levels. So schools quite commonly strip open online privacy to levels equal to national security contractors or government-operated-ISP levels. (again, everyone knows up front).
So if you're target audience is public (K-12) schools or businesses in the national defense game, yes it is a threat. In fact, for those target audiences, any shared service (hosting, SSL, email, etc) is an equal threat because of the possibility of being tainted by a co-tenant of the same service.
In reality, availability denial due to SSL sharing is a minimum risk for most folks who would use Shared SSL. Once you account for the security horribleness of the feature (it isn't security, it doesn't provide SSL protection, all it is good for is letting you keep a plain HTTP [no-s] web site without modern browsers slapping "insecure" all over it) the only reason to use Shared SSL is because you don't really need SSL at all except the browsers are making you.
Anyone who actually needs SSL should have their own certs without letting other folks touch the private keys.
