As soon as you connect the clouds and enable data stream, users, leads and contacts (no other objects) that feed into Synchronized Data Extensions, immediately raise your (billable) marketing cloud Contact Count - this is notably different from Data from other sources, say a .csv import (god forbid) - here, the contact is created with the first sendout.
This immediate raising of the Contact Count can be very problematic when you have large sets of "fake" or "non-final" data in your SF org that is still under construction.
Check your contract to see what your Contact Record limit is.
Test records will raise your contact count without any business value, and the count will remain high even after these records have been cleaned from Sales Cloud. You will have to run a contact deletion in Marketing Cloud to reduce your contact count.
Since waiting to setup the Marketing Cloud Connector until Sales Cloud is stable can be a big project roadblock - I've made good experiences with this approach:
connect the production Sales Cloud and the Marketing Cloud (see below)
Before synching objects:
Introduce a custom field (boolean) on all three objects like "synch to sfmc" and set it to false for all records.
Set a filter condition in the Data Source streaming inside Marketing cloud Contact Builder, so that you only accept users, leads and contacts with "synch to sfmc" = "true" flag into Marketing Cloud.
If you need a few records to test processes, then you can manually set their flag to true. Once your setup is stable, remove the filters or set them to "true" for relevant contacts programmatically.
The case can be made to have multi-org enabled and then connect separate BUs to sandbox and production respectively. The idea would be to connect the sandbox early on, and later the prod Org.
My (personal) suggestion at this stage (Feb 2020) is to not do this, but connect Marketing Cloud only to the production SF org. You might find different opinions on this, but what can be said is that sandboxing can be a very process-heavy endeavour and has some hard limits. What kills the concept in my opinion is that there is no push-button deployment for integrated usecases. This means you will have to work like this:
Build on Sandbox - Test - Deploy to Production with some manual interference - Retest on Production to ensure nothing was broken while deploying semi-manually.
Which means you already have a large workflow to manage, but could as well have started on Production and just tested iteratively.
By their nature, the processes you build in marketing cloud (journeys etc) are highly dependent on the underlying data.
Journeys, SQL queries typically break because of "wrong" (unexpected) input data. So in my opinion, properly isolated tests on Production are more helpful in identifying and fixing problems before they occur than tests in a sandbox environment with constructed data.
All this might change with Deployment manager becoming more and more powerful, but at this stage, it's not quite there.
Personal opinions aside, there is a lot of material on Multi-Org being used for Sandboxing, stating a lot of the "gotchas". Start here:
Coming back to my first point: Records from a connected sandbox count against the Contact count like production records.
New IDs get created upon Sandbox refreshes as well, so each time you refresh the sandbox, you run the risk of multiplying contact records.
Hope this helps!