This has been already mentioned on the wiki document, to get some functionality Moodle will need to issue SQL query against the log data. This means that Moodle will have to know the exact structure of the logging implementation. Only the interface methods for getting logs may not be enough.
One way to deal with it, would be to keep a minimal core SQL DB log table forever. So an even would be created but for some logs they would go to mdl_log as well. This could be a minimal set of log events with a minimal amount of data - just to suffice for common functionality that uses log table at the moment.
Another way to deal with it, would be to create a set of interfaces for each functionality that we need from logs, eg:
interface login_information with log_login_errors method to cover http://docs.moodle.org/dev/Logging_usage#lib.2Fcronlib.php.
This way, when some functionality would be required (e.g. finding failed logins since), log mechanisms would be queried. The first one that implements appropriate interface would be used. If none, then the feature would not be available.
Another point, invoking get_events like this:
$reader->get_events($select, $params, 'timecreated DESC, id DESC', $page*$perpage, $perpage);
looks to me like every log plugin will *have to* expose/store data in SQL table, is that intentional?