Accepted Solutions
We've done it all 
If you are using archive enabled databases, the best approach performance wise follows the idea of zipping. With replicas generated off archive enabled databases you can just generate a single copy of the database and then run GeodatabaseSyncTask.RegisterGeodatabaseAsync (GeodatabaseSyncTask.RegisterGeodatabaseAsync Method) from the client.
Generate the single copy of the .geodatabase and zip and store on the server. Download > Unzip > Register. We have done by storing the zips in Portal and just storing on a server and using HttpClient to download. The portal approach is nice because you can use the API for downloading and not need your own Web Server configuration (we have a custom rest service as an endpoint for that approach). If you are using versioned database this won't work, but I would highly recommend against a versioned database because it does not scale well at all.
We have also worked on breaking out replicas into more manageable sizes, so each only contains a small number of layers. An advantage of this is that if data does need to be replaced on the client it is easier to manage. The current sync tools do not allow for any schema changes. If for any reason something changes on the database side (add a new field) you need to push an entire new replica to the field. Breaking in multiple databases also gives you a way to manage syncing if some data does not change frequently.
Enjoy!
Ha!
Seems like we are on similar paths. Schema changes is actually what got me into the current situation I'm in... all because we needed to add a value to a coded value domain, which is a schema change (but that, I think, is for a different thread). I ended up migrating all of the domains into a separate table (instead of using Esri domains) so that I could update them with just a sync instead of a new replica.
I like the idea of breaking it into multiple databases, we do have reference data that we are downloading that doesn't update as often so using that in a separate database makes lots of sense. I have actually been considering using one replica "per layer" where a layer is the main table and its immediate related tables, although this would help a lot with downloading replicas when there are schema changes, it makes querying related records a bit harder.
Have you had any issues with many to many relationships in replicas? I ended up deploying that as two 1 to many relationships.
I have also been considering taking a very different route for syncing. In another application we rolled our own sync engine, and while it was not as comprehensive as Esri's is we were able to handle schema changes and only download those deltas. We were also able to handle partial uploads so if part of a sync worked, we knew what worked and what didn't which helped a lot with spotty connectivity. For this application, I have been considering switching to our own sync engine so that we could do peer-to-peer syncing in the field. For us, the most important thing is that the team in the field can get each other's data, and right now that takes a minimum of 2 syncs per person each evening over what is normally a 2G connection, and ends up being more than that when people don't pay attention or coordinate.
I have another project coming up that is only uploading data and I think we are going to just store that locally and push it as edits to the feature service instead of using a replica.
