So I hate to admit this, but now that OSCON is over, several days after delivering my presentation on Seaside and Rails, I figured out the actual conclusion.
People have taken my posts on Seaside and Rails as if they were discussions of Seaside vs. Rails. That just isn't the case; in fact it's silly. What it's really about is that there are design differences between these two frameworks, and while I don't think either one is the answer, I do think both are way better than everything else out there that I know about.
Rails' assumption that building REST into your app at such a level that APIs are almost auto-generated by default is the right way to do things; Seaside's decision to give Web app developers the same kind of power that desktop developers have is also the right way to do things.
When you look at Rubinius, it's entirely possible Avi Bryant's hypothetical Ruby virtual machine could in fact happen very soon. At that point, features of Seaside which were previously only available via Smalltalk will become available to Rails. At the same time, Gemstone is doing work to make Seaside applications much easier to deploy. Object databases like Gemstone's are pretty much necessary if you want to handle particular problem spaces, such as warehousing and inventory systems. Object DBs already exist for Java, so JRuby will make object databases available to Rails applications, which means you could use Rails for gigantic enterprise problems suited to object DBs. But if you did that, you'd need to rewrite ActiveRecord, since object databases give you active records by definition.
Basically, I'm indulging in some amateur futurism here, and there's lots of interesting things happening on that horizon.