It really depends on how you use the data.
If there are foreign keys to of from these tables to other tables that he is NOT moving – then you’re going to lose any hope of maintaining integrity.
If these tables are frequently accessed in the same session, then you’ll have to switch to db links with their own set of issues. Performance may suffer, and queries can be tuned to minimize the effect of the split.
As far as admin and backup, I think it’s easier to take care of fewer instances not more. Whenever given an opportunity – we consolidate. It makes more sense to move these tables into one or more tablespaces if they aren’t already.
The DBA might have other reasons to split the data off, but you haven’t really given us any compelling argument for moving the data to another database.
I really hate to second guess someone else without having all the facts, but the only reason I can think of to split the data up – is if these 3 tables are NOT associated with the other 30 gig of data AND the 2 databases have different uptime requirements.
Let’s say the set of smaller tables is an entire application that HAS TO BE UP all the time and perform reasonably well. The 3 big guys don’t have to be up all the time, and there are expensive queries running against them all the time. THEN it makes sense to split them off, so they don’t interfere with the critical application.
I hope this helps.