I would like to see non-federated portals more capable than the current setup. At this time we cannot justify federating our portal. When using a non federated portal I had noticed that there are some very important features that are missing:
Why do I think these should be allowed
Why cant I justify federating portal at this time:
Portal by design doesn't host any data, which is why the options for having hosted data (tile or feature layers) aren't available. All data in an ArcGIS Enterprise deployment resides within ArcGIS Server and ArcGIS DataStore, while being referenced in Portal. While ArcGIS Server can be used by itself, the other two pieces (Portal for ArcGIS & ArcGIS DataStore) are not designed to be functional in that same way, and it's why we call all three, when federated (Portal, DataStore, and Server), ArcGIS Enterprise.
If you are already paying for an ArcGIS Enterprise license, you would have the licenses needed to share published services with the other municipalities that are currently using them. Additional user licenses need to be purchased only when creating content within an Enterprise (web maps, web apps, publishing, etc.), not when the end user is only viewing content. Since most REST services are view only anyways, you would be covered on this front without having to purchase anything additional.
The main change that happens to ArcGIS Server after federation is that the security of users is then managed through the Portal UI, instead of Server Manager. Otherwise, REST services still function the same and can be shared like they always have been, and any published services will automatically be added to the Portal as content items. REST URLs don't change after federation, so applications or data links in MXDs won't break suddenly.