insert/update/remove are actually just "newbie helper" shortcuts on top of the underlying latency-compensated RPC mechanism (which is documented under 'Meteor.methods'.)
Once the auth branch lands, you'll have two choices.
One options is, you can turn off the shortcuts entirely, and write a method for each scenario where the client would be allowed to write to the database. This gives you the same security model as a REST API.
Or, you can register an authorization-check hook with insert/update/remove, so you can vet each write and decide whether to allow it or reject it. This might work well with an ORM where you've marked some fields as writable, and some as protected.
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.