Especially if it'll be a team of 10 developing with me, and 8 may leave in a month, then trying to find people with all those skills, which are certainly a bit hard to come by in my part of the world.

• think the other way around. every new person you hire might know one or the other framework, or maybe not. that doesn't matter, they must *all* learn *your* framework. if you were using a common cpan framework, some of them might already know it, and if not, they can learn it and they'll find help on perlmonks.org, for example, because they're not the only ones using it. yes, programmers can learn, and some of them even enjoy it.
• again, think in the perspective of the programmer. if you're hiring, they might not know catalyst, DBIx::Class, but that's no reason not to hire them because they can learn it. if you insist on your own framework and for some reason they leave your company after a while they have learnt a framework which isn't used *anywhere* else in the world.
• think about *your* perspective in the future - in some years maybe most programmers know catalyst and you can't hire them because they don't want to work in a company where everything is proprietary.
• don't think "it has worked for me all the time, why should i use something additional?" this *is* how some people think who haven't used better things. if you have used ORM or a web framework it is hard to go back to plain DBI or plain CGI scripts. of course an ORM might not fit everywhere, but then some other technique that saves the developer time.
• i'm not saying never ever roll your own, but you should at least know a bit about the existing modules out there before saying i don't want that.