Mason's great, and it's autohandlers and dhandlers take a huge amount of work out of working up a site framework; it as a reasonable nice OO-ish view of the world.
However, Mason is primarily an API - while a library of code is beginning to appear, it's nowhere near as rich as the one you get with OpenACS (which is why I've done some work on generating a Perl API to access the OpenACS datamodel). The datamodel and library of code in OpenACS is IMO the most compelling thing about it.
(For those wondering about autohandlers and dhandlers:
An autohandler is code executed upon every request to the site hierarchy living below it. By calling itself as a method operating on the pages, you can stuff all of your framework in the autohandler and everything in the directory tree under it need only be the content specific to that page.
dhandlers provide a convenient way of mapping default behaviour to a hierarchy when files corresponding to requests aren't available. One example would be a news site, where a request to /breaking/news.html would grab news.html if it was present, or gab /news/dhandler if it wasn't.
Since you can also trivially extract URI components from a request, your dhandlers can do nice clean variable passing - for example, for stories on our news site, we might have an /archives/dhandler. Pointers to old stories might take the form /archives/2001/2/32/greenspun, at which point the dhandler is invoked with 2001/2/32/greenspun passed as a variable. Do a split() and you're ready to populate your DB request, and silly spiders and proxys that refuse to handle GET requests in an RFC compliant maner are fooled.
)