Your specific questions:
1) There is no strict limit to the “number of entries” a DB may contain before performance is affected. Performance depends just as much on your hardware and configuration as it does on the size and structure of the DB.
2) If you’re worried about the scalability of your DB layer, you can run it in a cluster, or on a cloud box or VPS that allows resizing. If your DB starts to become sluggish, you can size up (though usually at extra cost). These options add cost, but are really the best way to ensure scalability of a DB.
3) This really depends on your hosting setup, and your DB architecture. But in general (unless you’re on a really cheap box), I wouldn’t worry about a 30MB WordPress database. WordPress does a good job of indexing tables, and even an OOB MySQL configuration should easily handle WordPress queries on a DB this size. When you get up into Gigabytes–that’s when you might need to look seriously at performance optimization options.
In general:
If you’re worried about performance, concentrate on tuning your existing MySQL setup, and/or setting up a caching layer. Caching can greatly reduce the burden on MySQL (particularly with WordPress sites, as they generally perform a large number of DB queries).
If after you’ve properly tuned MySQL and set up a decent caching layer, you’re still worried about outgrowing your hardware configuration, you could institue a policy of deleting content after x amount of time.
None of this stuff is specific to WordPress. And I’m not sure that the question has any answers that don’t apply to any website or application running on a LAMP stack. But maybe someone else has suggestions concerning MU table structures or other WP-specific DB tricks… I dunno.