You show that CGI is slow, and using CGI.pm is slow. That's nothing new.

However, you make unjustified conclusions based on that. You immediately point at the code size, but then get off track very quickly. You say strict.pm is 3k of code. Well, it's about 3k characters, almost all of it Pod. That's the same situation for the other modules. You're being at best ingenuous there.

You are really making a proxy conclusion for code size mapping directly onto processing time (more code is more things to parse and run), although anyone here can write a very small routine to take up all of your CPU for the rest of its existence. You've made a prediction, but you didn't do anything to verify it (such as making null classes or fiddling with %INC). You don't do what you should do next: profiling. All you know from your analysis is the run time. There is nothing in there to point at a cause.

Also, you get too caught up in the numbers. Those are only valid for your particular machine and setup. Not only are the numbers valid only in your case, but so are their relationships. I tried the same thing and got much better performance from a C script, as well as better relative numbers between a null Perl script and one that uses CGI.pm. A different situation gives different numbers, which is why benchmarks only really matter if you run them on the target platform.

Finally, you get to what most people found out in the 90s: CGI and CGI.pm is slow. So what? It's often fast enough for the task, even when the scripts do real work.