I am running flask/memcached and am looking for a lean/efficient method to prevent automated scripts from slamming me with requests and/or submitting new posts too quickly.
I had the thought of including a 'last_action' time in the session cookie and checking against it each request but no matter what time I set, the script could be set up to delay that long.
I also thought to grab the IP and if too many requests from it are made in x amount of time, deny anymore for so long, but this would require something like redis to run efficiently, which I'd like to avoid having to pay for.
I prefer a cookie-based solution unless something like redis can prove it's worth.
What are the 'industry standards' for dealing with these kinds of situations? What methods come with the least amount of cost/performance trade-offs?
You should sit down and decide what exactly your "core" problems in the scenario of your app are, and who your likely users will be.  That will help you guide the right solution.
In my experience, there are a lot of different problems and solutions in this subject - and none are a "one size fits all"

If you have a problem with Anonymous users , you can try to migrate as much of the functionality behind an 'account wall' as possible.  
If you can't use an account wall, then you'll be better off with some IP
based tracking, along with some other headers/javascript stuff.  Going by IP alone can be a disaster because of corporate proxies , home routers, etc.  You'll run the risk of too many false positives.  If you add in browser info, unsavory users can still fake it - but you'll penalize fewer real users.
You might want an account wall to only serve as a way to enforce a cookie , or it might plug into the idea of having a site identity where experience earns privilege
You might want an account that can map to another trusted site's account.  For example, I generally trust a 3rd party account binding against Facebook - who are pretty decent at dealing with fake accounts.  I don't trust a 3rd party account binding against Twitter - which is largely spam.
You might only require site "registration" to need solving a captcha , or something else mildly inconvenient to weed out most unsavory visits. If the reward for bad behavior is high enough though, you won't solve anything.

I could talk about this all day.  From my perspective, you have to solve the business logic and ux concepts first - and then a tech solution is much easier.
Leanest way to prevent scripted abuse of a web app?