I might just not be understanding enough about what you're saying. If you make edits to the data stored in AGO, how are those edits going to be merged appropriately with your enterprise geodatabase?
I can understand the decision to export a subset of data from ArcSDE and upload it to AGO on a periodic basis for sharing, consumption, etc. for viewers. However, if your GIS system of record IS the enterprise geodatabase and you allow edits to occur to a copy of the data via AGO using feature services, won't the data become disparate between AGO and your instance of ArcSDE?
On the other hand, if you are saying that edits via AGO wouldn't be merged back into your enterprise geodatabase then that is different. From a consumption standpoint, I agree that the outcome and end-user experience might be the same whether the data is stored in a geodatabase replica or whether the data is stored in a FGDB within AGO. The user should really not have any idea of the storage source behind what he or she is seeing. But, to me, comparing the two approaches is somewhat like comparing apples to oranges unless storing/editing data in AGO replaces the enterprise geodatabase entirely. The mechanism by which updates/edits/refreshes are made to the data viewed by the end user HAS to become part of the discussion since it has bearing on how the solution is architected. I don't think you can really separate the data updating from the data consumption from the perspective of an overall solution. But again, if you are saying that AGO would be the repository for all data thus replacing ArcSDE then I may have misunderstood.