Let me just see if I understand what you are getting at first. I assume that you are talking about running the BizTalk Server on its own SQL Instance, but running on a cluster where other active SQL instances will also be running. You are essentially sharing hardware and you are concerned that other applications can negatively impact your BizTalk environment. Is this right?
So obviously a “pro” is this will ultimately cost your company/client less money to implement as you can spread the cost of the cluster (or farm) off against several projects/programs instead of just BizTalk.
A negative is that if your hardware is not sized right you will have competition of resources and degregation of performance. The way we have BizTalk configured where I am is we have a 2 node SQL 2000 cluster (32 bit). One node is “dedicated” to BizTalk and the other node is “dedicated” to a Payroll application. Since this is a cluster, “dedicated” isn’t really a reality, should a physical node go down, the SQL intance will flip to the node that is available. This is all great in theory…until you actually lose a node like we did. We then had a Payroll run which consumed a lot of SQL resources. BizTalk hosts lost connectivity as the SQL Server was pinned and BizTalk host instances were bouncing like a Yo Yo. This lead to a disruption of service for BizTalk. So suffice to say I am a fan of BizTalk running on its own physical node(within a cluster). I am a fan of clusters, provided they are sized right( I dont think ours was) and provided the planning was in place to accomodate other applications.
Something you could propose if there are a lot of applications targeted for this is to ensure your have several nodes and perhaps even a “free” node that could be used in the event of a physical node failure. So potentially you could have an Active-Active-Passive solution. BizTalk running on an Active node, other applications running on the other Active node and in the event of a failure you still have the Passive solution to pick up the load. Or if there were several apps just spread them accross all three nodes.
Something you may also want to persue is the RAID/SAN disk configuration. A poorly configured SAN can lead to disk contention between these applications. It doesn’t matter what memory/cpu you have available if your IO is poor. Here is a good post on disk configuration: http://gregbeech.com/blogs/tech/archive/2007/05/22/san-configuration-for-biztalk-2004-2006.aspx
As you are know BizTalk lives and dies with Disk IO. If you have any doubts about the new configuration, i suggest looking into the PAL tool (http://www.codeplex.com/PAL) This tool takes a lot of the guess work out of performance counters (including Disk IO). If you have a bottleneck, you will have some “evidence” that you can take to your infrastructure group.