I work in a small team using CGI::App, and our basic class structure looks something like this:

• Superclass (rarely modified)
  • Utilizes classes for:
    • authorization/authentication
    • templating
    • site customization (in our case, different sites may need slightly different sitewide behaviour; we handle this through a plugin system)
  • Inherited by Application Class: calls:
    • API class(es) (for business logic)
    • Form handling class (for form validation and error handling) -- if necessary
      • Utilizes a config file
    • templates

The point of the above outline is this: sure, each run mode is a method in the application class, but generally speaking, the application class is but a small part of the project. The API(s) associated with the application are typically much larger (as they handle database calls, mail notifications, logging, etc.). While CGI::Application itself is a very small module, and provides a simple, flexible, framework, when you get into a site of any size, a much larger ecology of code develops. Each developer works in the area in which they are most comfortable: templates (designer), APIs (DBA or SA), application (web developer), etc. And then juggle positions every now and then to add spice.

Additionally, as perrin noted, if you're using a source code versioning system, you really should have few if any conflicts when working on the same application class. If each person were working on a single run mode, any commits to the tree could be easily merged with earlier commits as they would not be touching the same code -- each person would be working on separate methods of the class.

On the subject of APIs, I find that I typically like to write them such that I can pass some minimal information from my controller (application class) to the API, receive some data, and then pipe it into a template. If done correctly, this amounts to about two lines of code in the application class -- which makes the application class very easy to follow.

On the subject of application classes, remember the rule of thumb: if you get more than 7 run modes going in your application, you probably need to start thinking of dividing your application into multiple applications. When you get that many run modes, the class gets unwieldy to debug and maintain. This is particularly true in team environments -- any one of you may need to maintain the class in the future, and if it's too difficult to follow, nightmares, castigation, and finger pointing start to ensue.

A CGI::Application is, as you note, a controller. It's intended to determine the page flow of an application. As such, I find that if my APIs and superclass are well written, a good, clean application class ends up being incredibly sparse, and more like an outline of what happens when. You then go into the called classes and methods to determine the details.

So, in summary: your team will have a plentiful division of labor with a good CGI::Application framework.