This really depends on the site, the level of information being stored, and the TTL (time to live) for the record. Google tends to handle a lot of different accounts for people: gmail, YouTube, blogger, Android accounts, search histories, contacts, calendars, etc; all of the stuff a spearphisher wants. Likewise their app, Google Authenticator, changes keys frequently.
Your tax site is likely going for the illusion of security but they may have a legit reason, if two-factor is compromised, like let's say you're using an app on your phone and your e-mail goes to your phone and your phone is stolen, then it really doesn't matter much how long the passphrases are. However, if the TTL is long, then if the site isn't equipped to block a DDoS mask for someone brute forcing a specific account, then it is a great idea to go with a longer key length. If the credit system is anything like that of the states, then they're trying to protect your identity.
If the TTL is short, then shorter numbers are okay. So if they have 30 seconds to guess a 6-digit code there is less of a chance of an accidental collision. Most web servers don't allow as many connections per second as necessary to brute force a password of a length longer than a few characters unless they're commercial. Commercial servers tend to allow more simultaneous connections to the same database.
Ideally the application framework would notice the multiple attempted intrusions and lock the account immediately though, so again, back to UX not too long, but not too short.