Because most of the work for Seaside (and to a similar extent Rails) is in managing user interface state. That goes away with client side frameworks. At least most of the messy complex stuff - obviously persistence things are still kinda handy ;)
Its back to the future.
When you have worked with both you find that the back end stuff just gets in the way for the rich client frameworks. Its not to say that "classic" action/restful style web apps don't have a place (they have a BIG place, especially for content heavy sites) but its not a one size fits all.
You still need a backend, just not a complicated framework. The backend for my Cappuccino application does not have to manage any UI state. It just reads and writes to a db.
Merb has grown so large, I think at this point Sinatra is better for very small projects. Use Merb if you want something like Rails, but with better internals and more flexibility of companion technologies.
I see Merb as being like Postgres and Rails like MySQL. Both are good products. Merb is better put together from a technical perspective, but doesn't have the mindshare that Rails has. This means less plugins being created, and less search results on Google for your error messages. For advanced programmers this usually doesn't matter, but for beginners it makes Merb much less accessible.
For small sites, Rails is the ultimate in readable and simple frameworks.
However. For very small sites where the whole application is placed in one source file. For bigger sites where not all the controllers is placed in one directory. For sites which uses jQuery instead of prototype. For sites where thread-safety is important, the answer is Merb.
Now that client side frameworks like Cappucino and SproutCore exist, I don't really see the point in using Rails or Seaside.
I would recommend Merb as a replacement for dynamic, content-driven sites that people currently use PHP for.