In short, YES you should cluster the service if possible.
I have seen lots of posts on this and I think that some recent problems with SSO clustering (see my post here for fixes) may have caused people to shy away from it. If you are running SQL on a cluster, then you may as well tack on another clustered service and have that much more protection. If you are not running SQL in a cluster then clustering the Master Secret Server will probably not make much of a difference for you!
If you have a reliable cluster available and it seems to be managed well, use it and cluster the Master Secret Server. This is still the recommendation that you will get from Microsoft and still the easiest way to ensure that a hardware failure will not bring your BizTalk server to its knees. I realize that the manual process involved in bringing up another master secret server in case of a failure is simple and short, but it is still a manual process. This means that somebody has to notice the problem, diagnose the problem, and fix the problem. All of which turns into downtime in your production environment.
I have seen people take a lot of time to notice and diagnose the problem in the past, so even if the fix is a quick one, you may still have a few hours of "head scratching" time before the production support team realizes what's happening. Whereas if you have the master secret clustered, you will have a breif pause during the failover, then smooth sailing. Chances are that your apps will not be affected at all (unless you happen to be restarting your host instance at the precise instant the failover takes place, in which case you will be unable to start them properly the first time and will have to issue the restart again)
I absolutely, definitely, 100% recommend that you take the time to cluster your Master Secret Server. (Just don't enable the registry replication if you happen to get an old version of the MSS clustering docs)