After reading the posts on this thread I'm sensing you already kinda know the acceptable thresholds of data loss based on experience in the company. That being said confirm them with your business owners. While disaster recovery is and can be very complex and detailed, I'm trying to simplify it in this post.

You're dealing with very small databases, the IO cost to back them up is not daunting to your servers performance I'm sure (but then again I don't know the specs and you should check this before hand, I'm basing this off the low MB numbers you've mentioned and semi-modern hardware).

I propose based on what I've read:

Full Backup - Weekly (day with least SQL activity)

Differential Backup - Every 12 hours (excluding the time frame you take your full backup)

You haven't mentioned retention much so you'll want to determine that, don't forget about it or one day your drive will fill with the backups 😉

From a recovery standpoint though it will be pretty simple, restore the latest weekly full backup and then restore the latest differential.

If you do the differentials at 12 AM and 12 PM (again, assuming that's acceptable regarding workload/performance) you could have a failure at 9 AM, and you restore back to midnight, or if its in the afternoon you restore back to 12 noon. While this doesn't give you point in time recovery based on your details it keeps the recovery well within acceptance. (DBs using this strategy should be in SIMPLE recovery model as Point-In-Time recovery is not needed, you will let the engine manage your .LDFs)

If your DBs start growing quickly, the IO costs are going to increase and you will need to re-adjust, keep that in mind. DR is never a set it and forget it deal. Also, it's imperative to test the backups once you've implemented your backup strategy. If you're wondering why, here is a great read:

http://www.sqlservercentral.com/articles/Backups/93224/

Best Regard!