The query-validation-only approach seems scary to me. It'd be like, in rails, relying exclusively on before_save callbacks for authorization. My gut says that would be error-prone in catastrophic way. Also, not all data is public.
I tend to agree with you -- I think the write-validation-only model is probably too error-prone to use directly. But you could have a layer on top of it that that lets you declare a schema for your records, and mark certain fields as writable by certain users (with reasonable defaults.) That would be much less error prone, but might be too cumbersome.
At this stage, we want to give people a choice and see what they do.
Reads are handled in a totally different. You explicitly define what data a given client is allowed to synchronize down to their local cache (by using Meteor.publish to define certain database queries that are available for client subscriptions.) The client can run whatever queries they want against their cache, but the only stuff there is the stuff you explicitly let them subscribe to, so it's OK.
