I see you mention the argument for this change is:
However, I think this might be triggered for a different reason. Due to this recent announcement, the term “Application” to getting even more ambiguous. We already used it for these objects, and we also had integrations through sources like Azure, ServiceNow and others which are also called applications (or target applications). SailPoint is about to add a new meaning of the word Application for objects related to machine identities.
So I think this is moved not because it would align better to represent access, but changing this for all customers just to cater for MIS customers.
Also I think this does not necessarily should fall under “Access Model“ anymore. It used to be the case some years ago that applications were necessary to request access profiles without needing to request roles. But since this is now replaced by functionality allowing for direct requests for access profiles, this is no longer necessarily the primary function of Applications. Many customers only use Applications to perform password management. You can only allow end users to reset their password on an account on a specific source, if you create an Application object and map it to that source. Since password reset functionality is just like source objects not part of the Access Model. It makes sense not to add Applications under the Access Model.
I vaguely recall that Applications used to be part of the Access Model tab and was moved for this specific reason, or that it was planned to add it to the Access Model, but then decided not to due to this reason.
Based on this, It seems to me that this decision to perform this action is not truly based on the argument given, which is not very applicable anymore, but rather to cater for MIS customers as part of the last week announcement.
That would also explain why this short announcement was made specifically now.
Kind regards,
Angelo