I had a long detailed discussion with VMware regarding this. This was the outcome. SQL DB clustered is not a 100%, VMware will give best effort support for that. For vCenter and VUM I know this is a common config and it usually works. For SSO there are some known issues due to dynamic ports and named instances.But folks have been able to get it working. Bottom line is its not a 100% supported but VMware will give best effort.
So what is a 100% supported solution for application and db? Heartbeat product. That will provide you redundancy for not only the DB side, but also for all aspects of the vCenter like the IS, SSO etc. Problem is its very pricey but then again that is aa fully 100% supported way to go if thats very important.
Here is a confusing KB article, it appears as if they are taking about clustering the application side. After reading whats in the link below, I inquired and reached out to a few folks at VMware and I was suggested heartbeat for all apps and db clustering
To your point regarding your clients having to restart their vCenter after a SQL cluster failover. I think whats probably happening is during the failover the vCenter experiences hickup and the vCenter service goes down. I would check to see if the vCenter service is up after SQL has failed over. If not perhaps starting that would do the trick. If its still running, perhaps restarting it would do the trick. Not sure if restarting the vCenter server would be required. If the service does the trick, then maybe a loop can be put in place to attempt to restart the service after a failure to avoid any manual intervention. Hope that helps.