Interesting and good to know. So from your original post we have an identical architecture to what you are running with a SQL2012 DB on the backend. The only variation is that we stuck with GIS tier.
We saw a similar issue with non-displaying layers to what you initially described but I can't recall which of 3 possible issues was tied to resolving it.
1) We have a BigIP in play where we assign the VIP to load balance onto our IIS Web Servers in the DMZ. The BigIP had some caching turned on that we had to tweak at one point. We also have found that making significant web adaptor or ArcServer configuration changes requires us to turn off all the BigIP caching and then turn it back on.
2) The certificates while maybe not necessary we fully deployed to 3 locations: a) within Windows Certificate Manager on both the IIS Web Server ensure the Root, Intermediate and Personal Certificates are installed; b) do the same thing in A but on the servers hosting ArcGIS Server; c) from the Admin Directory http://<server_name>.<domain>:6080/arcgis/admin/login add all 3 certs to each machine
3) We have a need to allow Collector Access over our wifi network which is different from our hard line network. This was tied to networking and BigIP items but we had to create some specific iRules to allow proper access and once that was done we had to exclude the VIP we are using from the BigIP list for SSL offloading (i.e. we wanted our servers to handle it rather than the BigIP handling it).
Side item, in a recent convo with ESRI we were able to establish that it is their understanding that there is no scenario which will offer an SSO experience other than using Portal instead of AGO. Essentially, they stated that because the user Enterprise login is derived from ADFS in AGO and either the Web Server or ArcServer is hitting AD directly it gets handled as a mismatch. By that, ESRI stated the returns from ADFS if they were passed to the servers on backend even though username/password are identical it's a different format so the backend servers will always cause a prompt. We are going to investigate a work around to this which would involve using a service account as the controlling factor for securing the REST service but then during publishing to AGO choose to store the username/password combo into AGO and then it's just managing control to that REST service in AGO products that use it via group controls, etc.