Yes this is expected behavior. SOTI has a centralized cloud hosted enrollment service that is used to generate the enrollment IDs. The devices then utilize the same enrollment service as a lookup service to convert the enrollment ID to an enrollment URL that they can use to connect to the instance. Without this service the devices would not know what to do with an enrollment ID as it would be meaningless without the resolution of that ID to a URL. If you open the on premise MobiControl server to the SOTI enrollment service URL it should allow you to create an enrollment rule complete with an ID and URL. The devices can then use that URL for enrollment within a private firewalled network. The devices would not be able to use the enrollment ID however without also opening the device network to allow for connectivity to the enrollment service.

Enrollment ID/URL won't be available if a MobiControl server has no access to Soti services hosted  at mc-enroll.soti.net . As far as I know, mcsetup.ini file can still be used for legacy Android+ using OEM specific device agent, and for legacy WindowsCE/Mobile device platforms.

With Android 11 and onwards,  most hardware device vendors should try to get their devices certified for Android-Enterprise (AE) platform.   Some major advantages of using AE are the deployment of third-party apps and upgrades from managed Google Play store and other Googles services.  An MDM server needs to get a proper domain name and strong SSL certificate from reputable certificate vendor before it can support the above features on AE platform.  Hence having a totally closed network 7/24 is likely not practical.  

I have many corporate/governmental customers which use closed network over 99% of the time, but their devices and server (associated with valid domain name & SSL certificate) still need to get online for device enrollment, fimware/app upgrade or some other server upgrade/services in some scheduled time slots under strict control.

I can't rule out that there are some customers using some hardware device that are not AE certified, or have to use a 100% closed network, or have no access to Google services due to different reasons.  For such use cases, extra efforts have to be put in finding and testing device-specific workarounds to do something which are standardized, trivial and easy on all compatible device models of the AE platform.