The key here might be in that WaltW has only 5-10 users on his databases. With only that number, the advantages of a split database over not split shrink substantially. Network traffic would be relatively low regardless of how the databases are configured. Maintenance might not be a particular problem with so few users, either. If users don't have their own front-end, you don't have the issue of distributing an updated database and with so few users, updating a database residing on the server shouldn't pose a particular problem either. Also, it sounds as though the databases are on an internal server (not distributed to a customer) which reduces the problem of delivering an update.
All that said, I would still recommend splitting databases in a multi-user environment almost every time. If for no other reason than "just in case". Just in case we add users. Just in case the database gets really large, just in case I want to upsize, etc., etc. Whether the front-end is placed on the server or on each workstation would depend on network traffic issues. As for a user opening the database when not logged in to the network, that's easy to control with user level security and placing the workgroup file on the network. If he can't log in, the database won't open and there won't be any missing links. Of course, missing links can be handled in other ways, as Edski stated.
Corrupted databases - I cannot prove it one way or the other, but I'm inclined to believe corrupted "data" is less likely with a split database. I have written and maintained several split databases on Novel networks and on Microsoft networks - both types with their own level of failures resulting in ungracefull database exits. Over a period of several years, we experienced several corrupted databases - some on the workstations and some on the server. In all cases, if the database was split (most were), the back-end was never corrupted - whatever that might prove.
Just my 2, well maybe 5 cents worth.