Profile Manager - Why create Enrollment Profiles?

Question

So a similar question was asked previously:
Why use an enrollment profile?
I've read through it and I don't think the answers provided tell the whole story, so I'd like to ask again adding some of my own thought and clarifications on the previous thread.  This may be considered a "primer" by some - though I am certainly not the expert on Profile Manager.  I'm laying it out there to explain my understanding and off of that, ask a question.  If you are an expert, and understand how all this works, please just skip to my question below!
First, my experience and understanding.  (I urge others to correct/clarify where they see fit):
The previous thread attempted to make a distinction between the 3 different types of profiles:  Trust, Enrollment.and Remote Management Profiles.
I believe the proper 3 distinctions should be: Trust, Remote Management/Enrollment, and Configuration Profiles.
- The Trust Profile is basically a Profile (.mobileconfig file) that contains the Server Certificate that needs to be present to validate other signed Profiles.  It's a fancy way of packaging up the Root certificates.
- The Remote Management/Enrollment Profile is a Profile (.mobileconfig file) that delivers the Remote Management "connection".  It registers the device with the Profile Manager server and facilitates the ability to use PM/APNS to push various Configuration Profiles as well as commands (wipe/lock/etc).  It is *only* called an Enrollment Profile when you explicitly create one (more on that below).  Because an Enrollment Profile does not need to exist to enroll (or rather it will use the implicit "unseen" enrollment), this is the most confusing of the 3 Profile types.  It is further confusing because the term "Profile" is used almost elusively on the device and not within Profile Manager.  In fact the "Enrollment Profile" is the only one explicitly called a "Profile" within the management interface!
IOW: While it is not shown anywhere in Profile Manager, I believe that "Remote Management" (called a Profile on the device) is basically the *default* Enrollment Profile that is only inferred and seen when you use the Enroll function on MyDevices.  This means you don't need to create any Enrollment Profile to enroll your devices interactively via the MyDevices page.
- The Configuration Profile is a Profile (.mobileconfig file) that delivers specific settings.  These Profiles are applied to either Users, Groups, Devices, or Device Groups.  They can be automatically pushed to an enrolled device, or they can be manually downloaded from the MyDevices page (seems to apply to User configuration only) for devices even if they are not enrolled (this would allow the end user the 'choice' to pull down settings).
Having outlined that, the simplest steps to enrollment...:
When you setup Profile Manager, you can go right to the MyDevices page on your device, login, and choose "Enroll." (sample device is let's say an iPad)
Doing so will prompt you to install the "Remote Management" profile.
Note that when enrolling in this way it does not appear necessary to install the "Trust Profile" for your server, even when using a Self-signed Cert.  It would appear that this "Remote Management" profile contains not only the SCEP Enrollment Request and the Device Management payload, but also the Certificates that would be installed with the "Trust profile"
So we have seen here that one can enroll a device without explicitly creating any "Enrollment Profile."
So why use an Enrollment Profile?
Well according to https://help.apple.com/profilemanager/mac/3.1/#apd6DD5E89E-2466-4D3C-987E-A4FF05 676EB7, the answer is pretty straightforward:
"The user does not need to authenticate or log in to Profile Manager’s user portal"
This is a great feature.  For one, you can create an Enrollment Profile and send it via e-mail and the user doesn't need to visit a web page and login to enroll a device.  In fact, based on my experience Enrollment Profiles can't even be accessed via the MyDevices page unless you are a Server Admin.
However, when distributing an Enrollment Profile you seemingly *must* install the Trust Profile prior to this, or you will get an error about communicating with the server.  Several docs/tutorials you can google explain how to set up your deployment systems (specifically OSX machines) to deploy systems with both the Trust and Enrollment profiles to facilitate automatic enrollment when a new system is deployed so it can instantly be managed.
However, since a device that is already deployed will/may not have the Trust Profile installed, one would have to visit the MyDevices page to install that prior to being able to import a delivered Enrollment Profile.  Because of that it seems that from a distribution approach (as opposed to a deployment scenario) there is not much advantage of using an explicit Enrollment Profile anyway since we already need to visit the MyDevices page to get the Trust Profile, we might as well just use the standard MyDevices implicit Enrollment.
All devices that have enrolled themselves via a defined/explicit Enrollment Profile will be listed under that Profile in Profile Manager.  Devices that have enrolled via MyDevices will not be listed under any Profile, but rather just under Devices (where *all* devices will be shown regardless of how they enrolled).
So, now the questions:
So, the idea of an Enrollment Profile makes perfect sense - it is basically the only way to create an exportable profile that can be distributed and configured to automatically enroll a device without interactive enrollment via the MyDevices page.
What I don't get is WHY is there the ability to create multiple Enrollment Profiles rather than simply providing a default exportable profile?
The reason it makes no sense to me is there is absolutely no correlation (that I can deduce) between an Enrollment Profile and the devices that used it to enroll.  While I can see a (non-exportable) list of each device enrolled via each Enrollment Profile, it ends there.  I can't, for instance, create Configuration Settings that I link to an Enrollment Profile.  Or dynamically populate a Device Group with all devices enrolled from a specific Enrollment Profile.  If I could do these things, it might make sense to me and I have spent much time looking at the interface and scouring documentation to see where the connection is.  I have simply determined that there isn't one.
I can go ahead and create several Enrollment Profiles such as:
iPads
Lab Systems
Main Office Systems
High Security Systems
And I can deploy these Profiles (either via mail/file or via initial deployment) to the respective devices.  I can then see under each Profile which devices enrolled.  But, since I can't actually do anything to correlate those systems to a configuration, why would I want to do this segregation?  Sure it gives me a listing of iPads apart from OSX machines, but I can't do anything with this listing!
Now, of course, I can still pre-stage devices and add them into particular device groups so that as soon as they are enrolled (via any Enrollment Profile) they will get the Configuration Profile(s) attached to them.  This makes the inclusion of multiple Enrollment Profiles even more suspect.
Am I missing something?  Can someone enlighten me as to what the purpose of creating more than one Enrollment Profile would be?
We can easily say "Well it's not hurting having them there" but, in terms of complexity and confusion I believe it is.  Had they simply provided a single Enrollment Profile ("Remote Management") that was downloadable/exportable it would have been sufficient.
Thoughts?

Answer 1

So a similar question was asked previously:
Why use an enrollment profile?
I've read through it and I don't think the answers provided tell the whole story, so I'd like to ask again adding some of my own thought and clarifications on the previous thread.  This may be considered a "primer" by some - though I am certainly not the expert on Profile Manager.  I'm laying it out there to explain my understanding and off of that, ask a question.  If you are an expert, and understand how all this works, please just skip to my question below!
First, my experience and understanding.  (I urge others to correct/clarify where they see fit):
The previous thread attempted to make a distinction between the 3 different types of profiles:  Trust, Enrollment.and Remote Management Profiles.
I believe the proper 3 distinctions should be: Trust, Remote Management/Enrollment, and Configuration Profiles.
- The Trust Profile is basically a Profile (.mobileconfig file) that contains the Server Certificate that needs to be present to validate other signed Profiles.  It's a fancy way of packaging up the Root certificates.
- The Remote Management/Enrollment Profile is a Profile (.mobileconfig file) that delivers the Remote Management "connection".  It registers the device with the Profile Manager server and facilitates the ability to use PM/APNS to push various Configuration Profiles as well as commands (wipe/lock/etc).  It is *only* called an Enrollment Profile when you explicitly create one (more on that below).  Because an Enrollment Profile does not need to exist to enroll (or rather it will use the implicit "unseen" enrollment), this is the most confusing of the 3 Profile types.  It is further confusing because the term "Profile" is used almost elusively on the device and not within Profile Manager.  In fact the "Enrollment Profile" is the only one explicitly called a "Profile" within the management interface!
IOW: While it is not shown anywhere in Profile Manager, I believe that "Remote Management" (called a Profile on the device) is basically the *default* Enrollment Profile that is only inferred and seen when you use the Enroll function on MyDevices.  This means you don't need to create any Enrollment Profile to enroll your devices interactively via the MyDevices page.
- The Configuration Profile is a Profile (.mobileconfig file) that delivers specific settings.  These Profiles are applied to either Users, Groups, Devices, or Device Groups.  They can be automatically pushed to an enrolled device, or they can be manually downloaded from the MyDevices page (seems to apply to User configuration only) for devices even if they are not enrolled (this would allow the end user the 'choice' to pull down settings).
Having outlined that, the simplest steps to enrollment...:
When you setup Profile Manager, you can go right to the MyDevices page on your device, login, and choose "Enroll." (sample device is let's say an iPad)
Doing so will prompt you to install the "Remote Management" profile.
Note that when enrolling in this way it does not appear necessary to install the "Trust Profile" for your server, even when using a Self-signed Cert.  It would appear that this "Remote Management" profile contains not only the SCEP Enrollment Request and the Device Management payload, but also the Certificates that would be installed with the "Trust profile"
So we have seen here that one can enroll a device without explicitly creating any "Enrollment Profile."
So why use an Enrollment Profile?
Well according to https://help.apple.com/profilemanager/mac/3.1/#apd6DD5E89E-2466-4D3C-987E-A4FF05 676EB7, the answer is pretty straightforward:
"The user does not need to authenticate or log in to Profile Manager’s user portal"
This is a great feature.  For one, you can create an Enrollment Profile and send it via e-mail and the user doesn't need to visit a web page and login to enroll a device.  In fact, based on my experience Enrollment Profiles can't even be accessed via the MyDevices page unless you are a Server Admin.
However, when distributing an Enrollment Profile you seemingly *must* install the Trust Profile prior to this, or you will get an error about communicating with the server.  Several docs/tutorials you can google explain how to set up your deployment systems (specifically OSX machines) to deploy systems with both the Trust and Enrollment profiles to facilitate automatic enrollment when a new system is deployed so it can instantly be managed.
However, since a device that is already deployed will/may not have the Trust Profile installed, one would have to visit the MyDevices page to install that prior to being able to import a delivered Enrollment Profile.  Because of that it seems that from a distribution approach (as opposed to a deployment scenario) there is not much advantage of using an explicit Enrollment Profile anyway since we already need to visit the MyDevices page to get the Trust Profile, we might as well just use the standard MyDevices implicit Enrollment.
All devices that have enrolled themselves via a defined/explicit Enrollment Profile will be listed under that Profile in Profile Manager.  Devices that have enrolled via MyDevices will not be listed under any Profile, but rather just under Devices (where *all* devices will be shown regardless of how they enrolled).
So, now the questions:
So, the idea of an Enrollment Profile makes perfect sense - it is basically the only way to create an exportable profile that can be distributed and configured to automatically enroll a device without interactive enrollment via the MyDevices page.
What I don't get is WHY is there the ability to create multiple Enrollment Profiles rather than simply providing a default exportable profile?
The reason it makes no sense to me is there is absolutely no correlation (that I can deduce) between an Enrollment Profile and the devices that used it to enroll.  While I can see a (non-exportable) list of each device enrolled via each Enrollment Profile, it ends there.  I can't, for instance, create Configuration Settings that I link to an Enrollment Profile.  Or dynamically populate a Device Group with all devices enrolled from a specific Enrollment Profile.  If I could do these things, it might make sense to me and I have spent much time looking at the interface and scouring documentation to see where the connection is.  I have simply determined that there isn't one.
I can go ahead and create several Enrollment Profiles such as:
iPads
Lab Systems
Main Office Systems
High Security Systems
And I can deploy these Profiles (either via mail/file or via initial deployment) to the respective devices.  I can then see under each Profile which devices enrolled.  But, since I can't actually do anything to correlate those systems to a configuration, why would I want to do this segregation?  Sure it gives me a listing of iPads apart from OSX machines, but I can't do anything with this listing!
Now, of course, I can still pre-stage devices and add them into particular device groups so that as soon as they are enrolled (via any Enrollment Profile) they will get the Configuration Profile(s) attached to them.  This makes the inclusion of multiple Enrollment Profiles even more suspect.
Am I missing something?  Can someone enlighten me as to what the purpose of creating more than one Enrollment Profile would be?
We can easily say "Well it's not hurting having them there" but, in terms of complexity and confusion I believe it is.  Had they simply provided a single Enrollment Profile ("Remote Management") that was downloadable/exportable it would have been sufficient.
Thoughts?