Is using the AD home directory attribute to map the home drive really no longer a best practice?

I have read some articles that claim that using the Active Directory user home directory attribute to automatically map the home drive is a legacy method, deprecated, or not recommended. The second article I linked gives some good reasons why this is not recommended.

However, I have searched high and low and have not been able to find any official Microsoft articles that give this recommendation. It seems like the official stance is still to either use the home directory attribute, or to use folder redirection. Here's an example article from 2013 where a Microsoft MVP still uses the home directory attribute practice, in an article endorsed by the "scripting guys".

Does anyone here know the history on this and can provide a link to a more "official" recommendation as to whether mapping the home drive via GPO is now the best practice, over using the home directory attribute? Or is this something that has just been adopted in practice but never officially endorsed? If the latter, is there any functionality that is lost by not using the home directory attribute?

The HomeDrive attribute is not deprecated and will probably not ever be removed. The reason it's popular is because it was the first attribute that removed the requirement of using logon scripts to map a user's drive. Admins could now specify the home drive during user creation programmatically and not worry about maintaining a logon script. For small organizations with simple administration, this worked out well.

For larger organizations, business needs dictated that not all user accounts were equal and some needed to be separated from others. These organizations either continued to use or created large, complex, logon scripts usually checking the members group memberships to determine what drives to map where, to include their home drives.

These logon scripts execute during... wait for it... logon and if something went wrong, such as a network path was unreachable or access denied, they would hang. The default timeout for Group Policy processing is 10 minutes. This is where the whole 'login to your computer and go make yourself a cup of coffee while you wait' came from. So now you've got perceived performance problems and reliability problems because Group Policy errored out and didn't finish processing correctly. This of course generated support calls for Microsoft, a lot of calls spent troublshooting logon scripts for primarily mapped network drives.

And then magic, new Group Policy Preferences appeared with the Drive Map extension! The drive map extension also supports Item-Level Targeting for such thing as Group Membership. Now, all those support calls for drive mapping logon script errors could automatically be "resolved" by transitioning them to this extension. Since it's part of Group Policy, the extension is offically supported by Microsoft, while logon scripts were given a best effort.

Organizations now have a Microsoft Supported way to map network drives based upon group memberships, Microsoft reduced their support calls and time troubleshooting logon scripts, and admins could manage it all from Group Policy, wins all the way around. And, btw, you can use Drive Maps for mapping user's home drive, (use %logonuser%).