It's not like third-party plugins already had proper logging even when it was just an add_to_log call. Hell, core Moodle doesn't have proper logging - in fact the most critical instances (the type where a member of staff has broken a website by changing some setting and you need to find out who it is so they don't break it again after it is fixed) tend to be missing.
And when I'm slagging off third-party plugins above, I'm largely referring to OU internal ones that we developed. 
Unless somebody paid particular attention, we very often forgot to add logging, even though we have quite good compliance with code guidelines and suchlike overall.
Anyhow: I don't think the new API is a particular problem for developing new code. It doesn't take long to do and it's an opportunity to think about what you need to log (for example do you want two different log events, or the same event with different parameters). Also it means the log events are properly document (i.e. look in /classes/event, you can see them all - vs look in db/log.php to find it doesn't exist or hasn't been updated and contains incorrect information anyhow).
It is tedious for existing code, though. I have probably migrated more than 20 events now so I should know...
Good news is that in some theoretical future when we're not all far too busy, we might be able to use the new log API to improve logging performance. I think writing log entries to database is one of the biggest bottlenecks to Moodle scalability, because it's one of the biggest causes of database writes, and db writes are really the key limit to scaling in most setups.
--sam
