For your first question, I'm not sure what you're getting at. Are you saying that you don't think it's necessary to have a public DNS record for your domain? You're right, you don't, technically. The thing is, your domain namespace should be unique worldwide, and if it's subordinate to a namespace you already own, then you can be guaranteed it is unique. It makes life a lot easier if you have a public namespace when it comes to integration later
This advice goes back to Windows 2000 days, and it's still relevant.
For your second question, if you own a namespace, do not, do not, place your AD domain at the root of that namespace. Always, always, always, create a subordinate namespace for your domain.
You do not want domain controllers exposed to the internet. You will always need some kind of DNS "shim" to separate your domain controllers from your publicly-facing DNS, and in that case, you might as well simply host your root namespace there.
Having a separate namespace means you do not run into the pain and agony of keeping a split-brain DNS in order. That link from Dell gives a really good summary of the kind of issues you can run into.
Yes, there are solutions like Infoblox "DNS Views" (even Microsoft provides something like that now), but it requires care and feeding too. You need skilled people to set it up and maintain it properly. Otherwise, per the Dell article, it can be (it always is IME) incredibly painful if you have two disparate systems "authoritative" for the same namespace without these extra goodies.
If you have your web services in your root namespace, and perhaps other things like other namespaces for bulk email (to make SPF easier) or non-Windows systems or practically any third party service that you might want to share your namespace with, it is much better to keep your domain separate. If you might ever want to do those things (hint, if it's an enterprise or public organisation of any description, you will).
It's a tiny bit of security via obscurity. Not much, to be sure, but a little.
From a system management point of view, your DNS delegations and resolvers are that much easier. You have your root namespace, and that DNS server delegates the subordinate domain namespace to the DCs, which are authoritative for it. Any domain client can then do nice secure DNS registrations, the root DNS remains authoritative for the root namespace. The AD DNS zone can be safely set to scavenge stale records, since modern Windows clients are fine with reregistering as necessary. Of course you can still create static entries for your servers.
For name resolution, DCs have their resolvers configured to point to the upstream DNS, and for both external and root zone name resolution, it's nice and clean for both domain and non-domain clients. Obviously you would only allow your internal non-domain clients to query the internal domain namespace, not external clients.
I'd actually recommend having a separate subordinate namespace for internal non-windows hosts as well - that can be hosted on the upstream DNS, or delegated onto the Windows DCs, or even a completely separate DNS host. Or, if you've only got some nice modern Linux to worry about, join them into the AD domain, done.
Finally, I've been managing AD domains since 2000 (and NT domains before that), and literally the number one issue I've encountered with domain design is if it's been done under a split-brain DNS in the root namespace. The dreaded "single label" domain is way down the rank of domain problems, because it's quite rare. Much more rare than this root AD namespace issue.
I'm supporting an environment like that right now. The domain has 10s of 1000s of accounts and has been around since 2002. We have hundreds of web services, cloud services (multiple cloud provider), third party SAAS and PAAS integrations, telephony, external domains with disjoint namespaces, Windows and non-Windows non-domain systems in the environment -- all interacting with that root namespace and/or the internal AD. The poor DNS design authority and I literally spend hours each month pulling our hair out over it for one reason or another. There is a lot of manual handling to get around the problems it causes.
One more option is to register a completely disjoint namespace for the sole purpose of hosting your domain, while all the public stuff remains in the primary namespace. For examples, entities that register a enterprise.com/.org for their public namespace, and enterprise.net.cc or something for their Windows domain. That's perfectly fine, but then you have an additional management overhead of registering MXes and TXT records and creating custom UPNs (maybe) for your disjoint namespace to integrate with things like your public email addresses/cloud services. Doable, but a little more expense and work for not really much benefit. And you need to ensure that shadow IT doesn't sneak in using the "wrong" namespace and then suddenly it has to be publicly accessible as well.
TL;DR - the reason why there's no good advice on a "proper" way to do it is that there literally is no proper and manageable way to do it. There is no benefit from having your AD in the root namespace; there are plenty of drawbacks if it is there.
Unless you're in a tiny environment and you don't really care about your AD. In which case, I'd actually suggest that you don't bother with AD at all and simply go straight to Azure AD cloud-based identities.