Even with an unclean shutdown of plooped containers, it's usually enough to do a fsck. It isn't much different from shutting down real hardware during write operations. Since I'm guessing you'll be using a filesystem with a transaction log on those ploops, you shouldn't run into more issues.
As Brian mentioned, a proper shutdown of the host node will leave your containers clean and their ploops unmounted.
If you're using directory-based containers that use the same filesystem as the host node, you already have a small chance of corruption now. I think in practice there isn't much difference, only that you might have to consider recovery time. Many ploops might take longer to fsck than one host node's filesystem and might require a lot of manual interaction.
On the other hand, if your host node has a very large file system, fscking that could take a very long time, and that leaves all those containers down during fsck. Containers using ploop could be started in a staggered fashion after the host node comes back up, provided the host node itself has nothing to fsck.
You could mitigate that by having some sort of high-availability setup where the host nodes load their container data from central storage and switch each other on/off in cases of failures, but I guess that's going too far.
What are your reasons for considering ploop? We've considered it for faster performance through NFS, where the many small files in a container really slow things down. But since you're mentioning filesystem corruption, that's probably not your scenario.