From what I've read, your environment doesn't have any "official" DBA. It's hard to make a lot of concrete statements at this distance, but here are some things that I'd be mulling over.
Firstly, it's entirely possible that the IT staffer is correct and that the data needs to be on another server for some regulatory reason. Sometimes, the rules are the rules. They might have been negotiated by persons in the government (or legal system) without regard to how they might be technologically implmented. Even if the rules might not make 100% "logical" sense, you aren't going to change them.
Also, as a sort of over-arching thing, I would suggest that as long as the performance isn't harmed and the uptime, disaster recovery and other SLA-covered items aren't negatively impacted, it's really the IT staffer's neck on the chopping block. You aren't responsible for regulatory compliance (or you would be trained to be more familiar with the rules, I'm guessing) and the IT staff are responsible for compliance. If something goes wrong with the app or they violate some regulatory rule, they will have to live with the consequences. You get to say "The IT guys told me it would be fine." (If the system does have any sort of problem on the new server, I would certainly find out whether or not the problem would have occured if the database was on the old server.)
As a long-time DBA who has worked on a lot of consolidation projects, you generally want fewer instances, not more instances. (I'm not talking about dev/test/qa/production instances; we are only talking production here.) It's easier to manage a smaller number of instances and it keeps the licensing costs down. Sometimes, some people fall in love with the idea of high server counts, on the idea that more is better. "100 servers with 1 database each" is somehow better than "100 databases on 1 server".
Are they going to be moving those other databases with regulatory data to blades or has yours been singled out? If more databases will be moving, why is yours going first?
What kind of SLA do you have for your database? Are the blades capable of handling it? How do they know that? If the old server is clustered, are the new blades clustered? Will the uptime be the same? Or better? Is the storage going to be the same?
Are there external reports or apps that "know" that all of those databases are co-located on the same instance? How about MS Access databases or Excel worksheets that do data extracts? Yes, this sort of thing should be hidden behind a view or stored proc but I've seen many cases were it was not. You don't want to find out that you need to rework app code after you have moved the database. Any such work needs to be figured into the effort to move the database.
On a more negative tack, it is possible that the "IT staff" don't know enough about SQL Server to feel comfortable using SQL Server's features (logins, roles, permissions, encryption, named instances, whatever) to properly segregate that "regulatory data" on just one instance. You can look at this as "the IT staff need more training/someone needs to buy a DBA" or you can look at it as "the IT staff need to be comfortable using what they already know to follow regulations". Both are sane viewpoints, with pros and cons.
If there are performance problems on the current server, IT staff might expect to improve the situation by moving a database onto a different server. That might be true for at least some functionality of a particular database, but inter-database dependancies can be very problematic. Performance of linked server queries will not match performance of local queries, due to network latency, a degraded ability to properly optimize queries and the way that data is sometimes fetched. Sometimes performance is OK, sometimes it isn't. The best way to tell is to test your code before you go live on the new server. Once you are on the new server, it will be harder to do anything about poorly performing queries and this isn't the sort of thing you want to be surprised by. I've seen people run into this in the past. The response is generally to copy the data from the remote server to the local server, usually by SSIS or by use of a linked server. This is extra work and problems with the "staleness" of the data can crop up.
Futher, linked servers can be security holes if they are carelessly configured. If your IT team is primarily worried about access to regulatory data, this should concern them as well.
If a database has dependencies on the other databases, they are all part of the same system. Moving your database to another server will make it more likely that the system will fail because there are more things to fail.
Eggs and baskets are not a great metaphor, even though it is often used. Eggs do not depend on one another. Databases can depend on one another. Interrelated databases should be seen as a system. Moving one database to another server will make failure of the system of databases more likely because there are more things to fail.
The question then becomes, "If you take one of those databases offline at random, how is the entire system affected?" IOW, what happens if the old server crashes? What happens if the new blade crashes? If the whole company stops working if those other nine databases are offline, does it matter if your database is up or not?
