So I haven't found the cause of this. But I did find out that the IPsec Policy Agent isn't really needed in my scenario. In fact, it's there for backwards compatibility with older versions of Windows as described here:
Note: This service provides
compatibility with Internet Protocol
security (IPsec) policies used in
earlier versions of Windows. New
deployments of Windows Vista and
Windows Server 2008 should not use the
policies supported by the IPsec Policy
Agent service since those policies
support only a subset of the features
supported by Windows Firewall with
Advanced Security. Instead, new
deployments should use policies
created by using Windows Firewall with
Advanced Security to take full
advantage of the additional security
and features.
http://technet.microsoft.com/en-us/library/cc733433(WS.10).aspx
So I simply stopped and disabled the service and this log madness has ended. Fortunately, everything else on the server seems to work fine without it.
Legacy Answer; Updates from the future below
If already have some Linux/Unix machines in your environment and are comfortable with that format, I'd recommend using Syslog. There are a number of products that will forward your logs to a syslog server for you.
If you're just looking for log collection for legal/compliance reasons, anything will do, really.
Splunk is fairly popular log tool (I think it's based on syslog) that can do a lot of reporting for you. If you want analytics built in, it's a good place to start evaluating. It has a limited free version, but can pay to break out of those limitations.
You can also use Nagios to assist you with your Log Management, especially with some of the plugins and sidecar applications, but I'll warn that it's not trivial to set up.
UPDATE:
If you're not afraid of scripting, there are a lot of examples of Logging Scripts at the Microsoft Script Center Repository. (Fulfilling the down-n-dirty requirement...)
UPDATE 2015:
If you're not using Splunk, you should use ELK (ElasticSearch, Logstash, & Kibana) as your logging mechanism. While F/OSS like Syslog, it gives you so much more feature-wise. As far as shipping logs, you should use NXLog. It handles Windows Event Logs, and ships them as objects (viewable as JSON, which is how they're stored in ElasticSearch). While each log is slightly larger over the wire, you don't need to write long, painful, and brittle RegEx statements to parse the fields (like you do in order to make use of Syslog, or syslog-formatted logs sent to ELK).
Best Answer
The windows event log is robust enough to handle many events per second, so depending on how many events you are talking about (100 compared to 100000) per minute and what exactly you need to do with the data would depend on if I would use event log or not. If I just need to use it for troubleshooting the event log is pretty good for that but if I need to analyze the data I always end up putting it in a database or pulling it out of the event log and parsing. There are some tools for this but it is an unneeded step if you can go directly to a database.
I am not sure on the exact specifications but for lighter record insertion the event log should consume less resources than running a local SQL server. In terms of performance I would say the SQL server would be a much better bet than event log. I believe the event log is also stored in memory.
Keep in mind that the event log is also limited in size. If you need to retain a lot of logs you are going to need to run automated scripts to export this and ensure you have the event log settings correct so you dont lose information. If the event log is at its maximum size, no logs will be retained until it is cleared.
Event logs can be logged to a database or syslog, but honestly I wouldn't recommend that.
I would recommend you weigh your options but if you are talking about heavy transactions consider a database.