Should I switch my database LOG volumes from IO1 to ST1
(First two paragraphs are repeats of my comments.)

When Amazon specifies "log processing" as a use case, I'd suspect they're talking about infrequently-flushed IIS logs and the like, not database logs. And although ST1 is specified as not suited for "small, random" workloads, my reading of http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html#inefficiency would be that it's not suited for "small and/or random" workloads. But this, and your questions of how the limits are enforced/calculated, are probably something you need to get clarified from AWS.

"Will SQL 2014 automatically increase the size of units it writes to the log in response to an increase in log file latency?" I'm pretty sure it won't by default. But if you can afford some data loss risk, then delayed durability may be just what you need: https://sqlperformance.com/2014/04/io-subsystem/delayed-durability-in-sql-server-2014

If you do end up moving to ST1, AWS's online conversion option sounds far riskier than "Add a new ST1 volume to the mirror, take the mirror offline, move the log file from the old volume to the new one, then bring the mirror back up, failover, and repeat with the principal", which should work well for this. (Moving or dropping the primary log file with the database online is not an option.)