--use-rfc2307 should be enabled per default on provisioning/classicupgrade. It does not bring any disadvantages. Use case 1: We often have requests on the mailing list, about how to enable RFC2307 and the NIS Extensions. I meanwhile wrote a HowTo about that: https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC. Use case 2: Also --use-rfc2307 automatically does the schema extension (ypServ30.ldif). In that place of the AD, the Windows tools like ADUC track the next free UID/GID for creating users. samba-tool could use this, too and would automatically be ADUC compatible. But this would be a new feature request, if --use-rfc2307 is implemented as default.
Main argument: Forget for a moment about Windows. Think about environment Samba is run within. It is a *NIX application, it offers services deeply based on system functionality (file access, authentication and authorization, et cetera), and to work transparently it needs consistent translation from internal to system attributes at all times. Currently, there's no consistency. Or, more precisely, the consistency can only be achieved, if installation is not using RFC2307 attributes at all. However ludicrous it may sound - it is true. Samba uses two sources for mapping OS user/group identifiers to the internal (windows) SID's. idmap.ldb mapping (builtin) SID's to uid/gid's on domain controller and RFC2307 attributes from SAM. You may say that SAM is authoritative, thus there's no conflict. However, that may only be true for new provisions (and even then, I'm not entirely sure it is true). The issue is more apparent, when you upgrade existing domain. In my case, the upgrade created idmap.ldb with builtin SID's map starting from 30'000 (the idmap range for domain in the initial smb.conf), then imported existing user/group base with uids starting in the same 30'000 range. As a result, the idmap.ldb mapped "Authenticated users" gid 30'002 became "RemoteUsers" from SAM, and the rights set on sysvol and netlogon shares got screwed completely.