A few points about mod_perl:

• Apache::Registry is not without its traps. Badly written CGI programs will fail in mysterious ways, because they don't expect to be persistent. For an easier transition mod_perl provides Apache::PerlRun, which will avoid most of these at some performance expense.
• Besides the performance benefits, mod_perl has another great feature: it lets you go beyond CGI by providing hooks into all request phases, not just content delivery, and it provides access to the Apache API. This means writing Authentication or Logging handlers in Perl, dynamically dispatching to a specific handler at runtime, ... a whole new range of possibilities.
• As a consequence of this, a lot of useful modules are available, such as Apache::DBI which keeps database connections persistent in a transparent fashion, or Apache::Session which manages... sessions.
• mod_perl is very actively developped and supported, and there's an extensive guide to help out newbies, and several books are soon to be published.

About your point 3, most production users of mod_perl use a dual server setup: a front-end Apache serves static documents, and reverse proxies requests for dynamic documents to a mod_perl enabled back-end Apache. These can be on the same, or on different boxes.