I have not done much of this recently, because I now run a company that caters to companies and organizations that need small but interactive websites. However, when I was working on sites with over 100k daily users (as part of a team), we used only some of those tools. I'm sure others here have used more of them. I'll assume you're looking at application-level or middleware-level redundancy and not running a large single-OS-image cluster, which is any entirely different kind of beast.

Load-balancing is one key to scaling, and reverse proxies are another. If you have user accounts, you can scale those accounts out across disparate back-end systems as one form of load balancing. You need to make sure the front-end knows which back-end to use then, and you may need to make sure the user stays on the same front-end proxy for the whole session. Reverse NAT and round-robin are simple forms of load balancing that can be done easily. LRU and least-loaded take a bit more work. Reverse proxies are nice for making sure you're only generating dynamically what you need, and I've used that.

Database replication is one other non-Perl thing to consider. So are the other services you might need to scale out along with your web site, like SMTP. POP/IMAP, LDAP, or whatever else you use besides HTTP that is important to your web offering or services offered with it.

As for the Perl side of things, you didn't mention FCGI, CGI::Application::FastCGI, Catalyst::Engine::FastCGI, or any of the other FastCGI modules on CPAN. FastCGI gives you a long-running process with no per-hit startup cost that is separate from the web server software. Apache and IIS can both talk to FastCGI backends, and the backend can even be on a separate physical server from the web server software.

For more of the Perl side of things, which template system and which DB interface layer (plain DBI, DBIx::Class, Rose::DB::Object, Apache::DBI, or many others) are good questions. Setting up a thin object layer of your own over your DB entries works for some sites, but if you have lots of tables with lots of schema changes, you probably want something more maintenance-friendly. Development practices must scale, too, just like request handling.

I do indeed write unit tests for most of my web applications, but I'm sorry to say I usually don't hit full coverage. I usually have my code able to be run locally as well as over the web, so most unit tests are relatively easy. LWP::Simple is often enough to unit test things remotely, and sometimes even just a script wrapping lynx will do. More complex things do call for a more complex testing method such as WWW::Mechanize.

Most of my truly large and scalable web-based applications have actually been done using mod_php, MySQL, OpenLDAP, reverse proxies, and DNS round-robin for load balancing. I have used plain CGI with both PHP and Perl with moderate (10 or 20 separate backend servers) of horizontal scaling both with no reverse proxy and with a group of intelligent reverse proxies which could connect to the proper back-end server. Using mod_perl or FastCGI will let you do more with each backend machine, but you can scale with plain CGI in a pinch if you have the hardware budget and the rack space.