Active Directory + Google Authenticator - AD FS, or how?
We need to look at what's going on here.
AD FS is all about SAML. It will connect to Active Directory to use it as a SAML Identity Provider. Google already has the ability to act as a SAML Service Provider. Put the two together, so Google will trust your server's SAML token, and you're logging into a Google Account via Active Directory credentials.1
Google Authenticator, on the other hand, acts as one factor of an Identity Provider... usually for Google's own service. Maybe you can see now how it doesn't really fit in with AD FS. When using AD FS with Google, you're not really using Google's Identity Provider anymore, and by the time AD FS completes the hand off back to Google, the identity side is already finished. If you did anything, it would be configuring Google to require Authenticator as a supplemental identity confirmation on top of (but separate from) AD FS or other SAML identity providers. (Note: I don't think Google supports this, but they should).
Now, that doesn't mean what you want to do is impossible... just that it's maybe not the best fit. While it's primarily used with Active Directory, AD FS is also designed to function as a more generic SAML service; you can connect it to other identity providers than Active Directory, and it supports many different options and extensions. One of these is the ability to create your own Multi-Factor Authentication providers. Additionally, Google Authenticator supports the TOTP standard for multi-factor authentication.
Put the two together, and it should be possible (though certainly not trivial) to use Google Authenticator as a MuliFactor provider with AD FS. The article you linked to is a proof of concept of one such attempt. However, this isn't something AD FS does out of the box; it is up to each Multi-Factor service to create that plug-in.
Maybe MS could provide first-party support for a few of the big mutli-factor providers (if there is such a thing), but Google Authenticator is new enough and AD FS 3.0 is old enough that it wouldn't have been feasible to do this at the release time. Additionally, it would be challenging for MS to maintain these, when they have no influence on when or what updates these other providers might push.
Maybe when Windows Server 2016 is out the updated AD FS will make this easier. They seem to have done some work for better multi-factor support, but I don't see any notes about including a competitor's authenticator in the box. Instead, it looks like they'll want you to set up Azure to do this, and possibly provide an iOS/Android/Windows app for their own competitor to Authenticator.
What I would ultimately like to see MS deliver is a generic TOTP provider, where I configure a few things to tell it that I'm talking to Google Authenticator, and it does the rest. Maybe someday. Maybe a more detailed look at the system, once we can actually get it, will show it's in there.
1 For the record, I've done this. Be aware that when you make the jump, this information will not apply to imap or other apps that use the account. In other words, you're breaking a huge part of the Google account. In order to avoid this, you'll also need to install and configure Google's Password Sync Tool. With the tool, every time someone changes their password in Active Directory, your domain controller will send a hash of the password to Google for use with these other authentications.
Additionally, this is all or nothing for your users. You can restrict by endpoint IP address, but not based on users. So if you have legacy users (for example: alumni users at a college) who don't know any Active Directory credentials, getting them all moved over could be a challenge. For this reason, I am not currently using AD FS with Google, though I'm still hoping to eventually make the leap. We have now made that leap.
I think your question makes the invalid assumption that it is Microsoft's job to add support for a particular vendor's 2FA/MFA solution. But there are plenty of 2FA/MFA products that already support Windows and AD because the vendors have chosen to add that support. If Google doesn't think it's important enough to add support, that's not really Microsoft's fault. The Authentication and Authorization related APIs are well documented and free to use.
The blog post you linked to sample code that anyone could write to add RFC6238 TOTP support to their own AD FS environment. That it happens to work with Google Authenticator is just a side effect of the authenticator supporting that RFC. I would also note the litany of disclaimers at the bottom about the code being "proof of concept", "no proper error handling", and "not created with safety in mind".
In any case, no. I don't believe Google Authenticator support will explicitly be be supported in Windows Server 2016. But I don't think anything is preventing Google from adding support themselves on Server 2016 or earlier.