Used it early and extensively for a pretty good sized project. In my experience what really happens on a long-lived project is that you end up writing and assembling your own framework on top of the basics that are provided. Not a bad thing if you think you're gonna end up growing a lot of your own infra anyways..
I think mostly I'd use microframeworks like this in the future to do small projects and early prototyping.. or if I thought the project had special needs that was going to make using something like Django a particularly challenging match.
It's an interesting dynamic. I'm going through a similar thought process except one level of abstraction higher (at the pseudo-CMS level on top of Django). I'm sure similar debates happen at lower levels of abstraction too.
You've got to decide for yourself where your 'reinventing the wheel' cutoff point is. For some people it's flipping binary bits, for others, anything lower level than configuring Drupal modules is just a waste of time.
What WSGI server were you deploying on? I'm thinking of using Bottle for some providing some REST services, so any details you can provide would be helpful.
I can't speak for the parent poster, but I deployed bottle with the grandparent poster without any significant performance issues*. This was first under mod_wsgi, then paste.deploy once mod_wsgi got to be a headache, and now I'm looking at gunicorn as a simpler alternative to paste.deploy.
So, why the asterisk next to "no issues"? I was able to wedge our app once by doing frequent, unbuffered, blocking socket.reads for one byte at a time in our RPC library... the GIL is a fearsome thing and it didn't play well with this strategy under highly concurrent request loads. I don't see that as a bottle problem, though.
I'd be curious for the details other asked for (define high rate, and how did you serve bottle)... Bottle services requests admirably. Not much there other than regexing your path and calling your function. If you had scalability issues I'd be tempted to believe it wasn't bottle code that was causing your problem (assuming you were using a real webserver to serve bottle workers).
I think mostly I'd use microframeworks like this in the future to do small projects and early prototyping.. or if I thought the project had special needs that was going to make using something like Django a particularly challenging match.