If you run php as a module, it is compiled with the Apache.
If you run php as a cgi, it is treated as a separate executable and must be called each time.
Apache is more efficient at executing php, than if you were to load it via cgi. In a smaller hosting environment, you won't notice much of a difference. My suggestion would be to use php as a module of Apache. However, if you are wanting to educate yourself, I would suggest trying out both instances of executing php code.
Using the module has a slight performance gain, since it's compiled into the Apache binary, meaning the PHP interpreter runs in the Apache process. So, when Apache spawns a child, each process will already contain a binary image of PHP. On the other hand, CGI is a bit more secure, in that the server manages control and access to the binaries. Although, most security holes are due to the scripts themselves. There are a lot of poorly programmed PHP scripts out there.
And, while CGI is slower there are solutions to that, such as FastCGI. If you are using a threaded MPM, then you'll want to avoid mod_php, since there are some extensions that are not thread safe, which will likely lead to race conditions.
Personally, I prefer FastCGI to mod_php. If a FastCGI process dies, a new one is spawned. I've seen instances where mod_php has killed off Apache entirely.
I use mod_php for Apache2 and speed it up with eAccelerator, but since mod_php includes PHP in every Apache instance it increases the overall memory footprint for Apache so have a look at how this impacts your own server (not sure how many concurrent requests / child processes you have on the go or what memory you have in your machine?).
As Jason has suggested an alternative you could look at is mod_fcgid, running FastCGI as separate processes (much like apache) spawning instances as needed; reducing the footprint of your Apache instances and only using as many CGI instances as required.