When looking at the potential importance of those log servers to the security of the organization, I wouldn't even hesitate to implement multi-factor authentication on them. PCI DSS primarily requires the audit trail for reporting the aftermath of a breach, and that means money. If breached, you can use that data to say "the attacker hit payment system X from January 3-10, but never entered the database", which can limit your liability to the seven days of data that flowed through system X. Without trustworthy logging, the investigators could claim "it's unsure, so we're finding all data from October through January is at risk." That could be the difference between thousands of accounts vs millions; which could be the difference between sending a few notification letters vs ending up on the nightly news. Both are bad, but trust me, one is much worse.
Those are just the worst-case costs. Architecturally, that log data is the ideal place to plug in analytic engines to help you detect anomalous activity early, and can help you identify an intrusion long before the attacker makes off with your data. So while many intruders are of the snatch-and-grab type, some of the more serious APT threat agents try to cover their tracks, and look for ways to disable logging and analytics so they can remain hidden for a long time. Don't make it easy for them.
And if you have a 2FA system in place already for accessing the rest of your in-scope machines, it shouldn't be too much harder to extend that capability to your log server as well.
However, the official answer is going to be "whatever your QSA decides is secure." Multi-factor authentication will certainly make it that much easier for her to sign-off on that requirement. But really, you should want those servers to be secure, even more so than the auditor.
