Canyon_IT, the short answer is that the Azure AD app proxy acts as a reverse proxy so you don't have to directly expose the NDES server to the internet.
Here's the recommendation in the docs:
We recommend publishing the NDES service through a reverse proxy, such as the Azure AD application proxy, Web Access Proxy, or a third-party proxy. If you don't use a reverse proxy, then allow TCP traffic on port 443 from all hosts and IP addresses on the internet to the NDES service.
Configure infrastructure to support SCEP certificate profiles with Microsoft Intune - Azure | Microsoft Docs
To further clarify in case I've missed answering your question:
There are two "connectors" in play here. Each is installed on an on-prem server to facilitate communication for different purposes. One to allow communication from NDES to Intune and the other to more securely allow client's to connect from the internet to your NDES service.
1. The Application Proxy connector connects your Azure AD application proxy (and thereby any client on the internet) to your on-prem environment/application (in this case NDES). This is so that it can proxy traffic in (often called reverse-proxy) so that your NDES server isn't directly exposed to the internet and thereby the attack surface is reduced.
Note: Azure AD app proxy actually only requires outbound firewall rules (no inbound needed), so it's super secure - Understand Azure AD Application Proxy connectors | Microsoft Docs
2. The other connector, that you install on your NDES server, is the Intune connector that facilitates communication solely between the NDES service and Intune. This connector exists so that NDES can validate the challenge presented by the client with Intune (i.e. it's just an additional layer of validation). Intune only returns a positive or negative response.
The external URL referenced in the post above is the one provided by the Azure AD application proxy. This is the one used in the Intune certificate profile and is the URL the client reaches out to with it's request. The app proxy then proxies the communication with the NDES server, because you have added the internal URL of the NDES server to the Azure AD app proxy configuration.
As far as not matching the console, that's not too surprising. Things change often in Azure and this post is pretty old by cloud standards. If you find you have a specific question once you have a license, don't hesitate to ask.