The Ruby AST -> SQL String -> PG SQL AST -> Plan process is a nice reminder of why we should use prepared queries wherever possible.
Of course this sort of approach would give up the (debatable) interoperability capabilities of SQL and I'm not sure parsing is enough of a bottleneck for it to really be worthwhile. A "binary SQL" spec would also be interesting (and maybe exists already?).
Not sure if it's exactly what you're getting at, but SQL Server has a "USE PLAN" hint that lets you set the entire query plan (using an XML string).
PostgreSQL's policy is strongly against hints, so we're unlikely to see anything like that in Postgres.
There are other reasons to use prepared queries but if performance is your only one it may not be worth it unless your query is either very complex, or runs in a tight loop.
Newish versions of Postgres (9.2+ I believe) try to paper over this surprising effect by re-planning queries a few times to check for cost stability before really saving the plan. It has proved very practical.
See http://www.postgresql.org/docs/9.2/static/sql-prepare.html's notes section, reproduced here:
Notes
If a prepared statement is executed enough times, the server may
eventually decide to save and re-use a generic plan rather than
re-planning each time. This will occur immediately if the prepared
statement has no parameters; otherwise it occurs only if the generic
plan appears to be not much more expensive than a plan that depends
on specific parameter values. Typically, a generic plan will be
selected only if the query's performance is estimated to be fairly
insensitive to the specific parameter values supplied.