Since I plan to delete this user, some sample "answers" for permanent reference.
We got tired of how badly Selenium handled XPaths, and the fact that XPaths were the main cause of us having to maintain scripts every time there was a minor layout change from the coders. We successfully trialled and then purchased several licences of a product called LiquidTest. We no longer have to combine multiple tools like Firebug and Python scripts together to create a test that will actually run.
The teams finishing projects with Selenium are jealous of the teams on the newer projects using LiquidTest, and they can't wait to get involved or be on the next new project. That's a good sign in my books
I have found XPaths to be more trouble than they are worth. They're ok if you're not changing the pages your testing, but if you're not changing them, why not spend less effort testing them.
When my CTO factored in the cost of the man hours editing the Selenium scripts to work every few builds, we realised that it provided us with a poor return on investment. We've spent some R&D time hunting alternative tools. The latest is a trial version of a a tool called LiquidTest. It seems less brittle so far, using other references to objects before resorting to XPaths. It runs in Eclipse, records tests through the browser UI and can write JUnit, Ruby, C#, etc. so all the Java coders here picked it up almost immediately. So far so good.
The problem with Selenium RC as far as I can tell is that it was created by a third party. Even Jason Huggins has trouble making RC work - http://clearspace.openqa.org/message/48380
We trialled and purchased a product called LiquidTest that lives up to their claim that it makes test record and replay as easy as it was meant to be. It handles dragging splitters in our ExtJS framework pages, and replay works just fine without hacking or adding python.
There are a few answers that could be construed as valid, but the overall pattern is very strong and consistent -- astroturfing.