That's not entirely accurate. Authentication in Windows can fall back to NTLM for a variety of reasons, including a malicious endpoint purposefully "downshifting" the version of NTLM it wants to use during a negotiation. There are tools to let you control the version of NTLM and group policy and what not...but that can break things that you have had for a long time.
Windows will do Kerberos by default and avoid NTLM in lots of situations, but it's hard to keep it from being used at all if that's your goal.
I'll add to that - It is still very easy to hijack SMB connections and use it steal the NTLM hash in almost any network with Windows machines (Managed with a DC or not). Just go ahead and try [1] (Disclaimer - running responder.py without authorization might be considered as a crime and I do not take any responsibility for it. I encourage you to use it only if you understand what you are doing and you have full permission to do it).
That's why MS recommends that you use a separate forest for admins only these days. You only administer things with remote tools via a trust, you only enable admin perms as long as you absolutely need them, and you put admins in the protected users group so that they can only do Kerberos. It won't stop other peoples credos from getting stolen, but it makes complete ownership of the domain less likely. That being said if you have service accounts running as domain admin, or you have service accounts with "delegate to any service" perms...all bets are off.
Its so hard to get this right these days. I'm just recommending that people move all their clients to Azure AD join and put servers in resource forests.
NTLM has got to go and hardware/virtualization based security like device guard has to become the norm.
Windows will do Kerberos by default and avoid NTLM in lots of situations, but it's hard to keep it from being used at all if that's your goal.