The big performance issue is in adding new messages to the database; Xapian isn't terribly zippy, but I was able to average about 80 messages/sec for 700000 messages using notmuch while sup managed only about 20; profiling showed that most of that delay was in running the ruby message parsing code.
The Ruby UI is also sluggish when presented with a long list of messages or a large message to display; sitting there for seconds much of the time.
For me, it was the Apple Newton that demonstrated why I never want to write any 'mission critical' applications in an interpretive language. The Newton shipped with most of the applications running in an interpreter. I'm sure it was easier to develop them as a result, but the end product was mocked in large part due to poor performance.
My other complaint about Ruby/python/perl/misc is fairly simple -- I expect the computer to detect and complain about my programming errors as soon as possible. Static typing errors can be detected during compilation and need not wait until execution time. Any language which passes the burden of this mechanical process on to the programmer is one where programs will have numerous latent bugs, and sup is no exception -- it crashed many times each day with various type errors. Yes, I know, dynamic typing is all the rage; I guess I'm just old fashioned.
In any case, I program in a lot of different languages as I believe that one should choose the tool appropriate to the job at hand. It may be that sup was best written in Ruby, I don't frankly know as notmuch is *not* a sup clone -- the bulk of sup is the UI, which is really quite good and notmuch tries to present a clone of that through emacs while re-implementing the Xapian glue code in a much faster (and type safe) language.