LINK #6 FileMaker Design: Single database with many tables vs. many databases
LINK #7 advantages of consolidating multiple files into one
If one of the files ever corrupted, the system won't fall over, same can't be said of the tables route.
File corruption is file corruption. If one of the files are corrupted, you have a problem that has to be resolved whether your system consists of 1 file or four. Recover can almost always repair your file to the point that you can import the data from it into a clean, uncorrupted backup copy.
Using multiple files with a file in each plus an interface file will complicate the design your solution--especically when it comes to managing accounts and passwords to control access to your database as you have to set up accounts in each file. Calculation Fields that combine data from two more related tables will also complicate your design as you end up with four relationship maps instead of 1 to manage and maintain.
That doesn't make doing it that way a bad idea, but you do need to "count the cost" to see if the benefits merit the extra trouble you have to go to.
A possible compromise is to use two files instead of four. This puts all your data in one file and all your scripts, layouts, value lists, etc in the other. This is called the Convert to Seperation Model and it allows you to deploy updated interface files without having to import any data as you just swap out the old interface file for the new and this can reduce the amount of data imports you might need to do when deploying a new version of your database.