I was working with HTML::Mason before I started using Catalyst - it was comments from one of the Mason developers about Catalyst that lead me to it.

Most Catalyst users seem to stick with Template::Toolkit, but I prefer just embedding Perl in HTML, and Mason is great for that. You'll be able to use most Mason features in Catalyst, but ignore dhandlers; Catalyst takes over their role. Make sure that you use Catalyst:View::Mason and not Catalyst::View::MiniMason (that may not be the correct name), which loses many of Mason's most powerful features (like autohandlers).

You'll most likely want to use DBIx::Class::Schema to handle your Catalyst models. Catalyst is model-agnostic; you can implement your models however you want - but DBIx::Class::Schema is very well supported out of the box, with Authentication and Session plugins ready to work with it.

Many Catalyst users end up using fcgi instead of mod_perl. It's minimally slower and provides more flexibility - it's easier to make multiple sites work under one server, and you can restart a site by restarting the fcgi processes rather than restarting Apache.

One of the key things a lot of people working with Catalyst (and I assume RoR as well, because it's not really a Catalyst issue) have problems with is where the logic of the application goes. I've been guilty of this myself. Try to think of the model not as just a database but as an API to the application itself, so that you could (if you wanted) provide a command-line interface to the application by wrapping appropriate code around the model and not using Catalyst at all.

A benefit of that approach is that it's easier to write unit tests for the model. It also tends to lead to less duplication of code, and is generally much cleaner.

I've been very happy working with Catalyst. It's actively maintained and evolving and has a small but very helpful community of users online. The mailing list and IRC channel are great resources.

The biggest warning I have about it is to be careful with the online documentation. Google will often turn up old versions of online docs, and it's easy to accidentally be coding against documentation for a module which is several generations old because Google didn't get you the current generation. I've had this happen to me, and I've seen it happen with people on the mailing list too. The community puts a lot of effort into keeping the documentation up to date, but can't control what Google returns.