these particular optimizations aren't caching any data from the database.
They are only caching calculations internal to AR. So you don't need to worry about using cached data when the actual external data has changed, is one thing.
The caching here is only of things that can't possibly change, essentially the output of a function for a given input.
Your memcache suggestions are a different sort of thing entirely, which certainly may be helpful for some apps in some circumstances.
Anything you can use to take load off the DB, which in turn may hit some sort of blocking I/O call (SSD or HDD) is a very Good Thing (TM). Or a sleeping heroku dyno. ;)
The optimizations being discussed in OP do not take any load off the db. They only reduce CPU time for AR to calculate what it's going to ask the DB for.
Seriously, have you read the OP? The optimizations in the OP do not prevent AR from asking for the same thing more than once. They do not effect how many times AR asks for things at all, as far as they can tell. It is _not_ caching database responses. It is caching internal AR calculations only, and does not reduce the number of times AR asks for things from the DB. Unless I am misunderstanding.
They are only caching calculations internal to AR. So you don't need to worry about using cached data when the actual external data has changed, is one thing.
The caching here is only of things that can't possibly change, essentially the output of a function for a given input.
Your memcache suggestions are a different sort of thing entirely, which certainly may be helpful for some apps in some circumstances.