My understanding is that nothing reads from the redo logs, unless recovery is required. 

Well, the archiver will and if you have standby database, then we'll be dispatching redo from the primary to standby pretty much continously. An AWR report can show you I/O distribution by file type, so you can use that confirm whether its redo or controlfile. But let's assume the latter.

There is still lots of *potential* causes here to be looked at.

First of all, 'log file sync' is time you waited for LGWR to get back to you, but that might be (or might *not* be) synonymous with LGWR I/O. You should check the ration of log file sync to log file parallel write to see how much of that time is truly based on waiting for LGWR I/O.

For example, smash a machine to 100% CPU and you'll sessions all stuck on log file sync because LGWR can't get a look in on the CPU, so everyone waits. So CPU is a good place to start.

Are you doing direct mode operations? Direct path loads, or NOLOGGING operations result in controlfile operations. Sometimes these can be happening even without knowledge, eg if you have SQL that uses the "WITH" clause, we might dynamically create and load global temporary tables to support this.

Backup activity can result in lots of controlfile operations - because RMAN is tracking a lot of its progress and results via the controlfile.

Do you have standby database? Again - controlfile used to coordinate activities there.

Similarly, how many archivelogs do you have "in play". Metadata for there will be stored in the controlfile - check the size of archivelog information in V$CONTROLFILE_RECORD_SECTION. Big = pain

Along similar lines, anything the interrupts archiving (eg disk full) will typically result in LGWR/ARCn etc losing the plot and going ballistic on the controlfile as they try/retry etc.

So that should give you some stuff to start with - if all else fails, might be time to get in touch with Support.