The answer to this is it depends.

If you need a clear security buffer between the databases so that someone with sysadmin rights to one database can’t have sysadmin rights to another database then seperate instances will be the way to go.  However this separation will come at a cost.  You now have to use twice as much memory loading up the SQL Server binaries into memory, and you now have to tell the instances how much memory each one can use.

With a single instance you simply tell the SQL Server leave 1 Gig of RAM for the OS (or how ever much you leave) and manage the rest for all the databases on the instance.  When you have more than one instance you have to decided how much memory each instance, and therefor each database will get.  If you guess incorrectly your database performance will suffer greatly because of it.

Another place where you may see some pain is your tempdb performance (assuming that both instances use the same tempdb).  Because you are using two difference instances the SQL Server doesn’t know anything about the load that the other one is trying to place on the disk.  If they both try to hit the disk at the same time with a large amount of load you could end up with additional queuing at the disk that you may not see when using a single instance.

Generally speaking I would recommend using a single instance unless you absolutly had to have a security seperation with the RAM settings being my biggest reason for a single instance.

As for reasons to need a seperate instance databases that need access to features that other databases shouldn’t have access to like xp_cmdshell would be one reason.  Applications which require sysadmin rights to the instance thanks to crappy coding would be another.  And a vendor which requires that there support account on the database have sysadmin rights would be a third.  Off the top of my head those would be about the only reason to seperate the instances.

Denny