It's not, though, a simple matter of caching search queries. I think optimizing RS is just going to be a lot of analysis and work.
There is a lot of cacheable information, and some of it could use an outside cache like memcached. But even within particular PHP scripts, there is information that can be cached pretty simply per script in php arrays alone (like keyword resolution). I wouldn't say 'most' of the queries could use the memcached type of caching, as this presents new problems in terms of the freshness of data, but it could extend the type of caching I mention (like keyword resolution) beyond the per-script basis. Caching like this is often worthwhile, but it does take work.
On the other hand, there are some functions in RS like get_resource_field_data() which are inefficient and used on scripts which are harder to evaluate with tools like the performance footer. I have begun to implement alternative algorithms for this one in certain scripts in Prismpoint Portal. The main inefficiencies there are twofold: 1. all resource data is gathered, even if a subset is required, and 2) in the case of multiple resources, repetitive queries to get field information, and then joins to resource_data which in my experience can become slow in situations like this.
But yeah! Any ideas about how to optimize RS are great! I expect that as the larger installations with good support grow, there will be general improvements in all these areas.
Tom