Not in the way you're talking about. You have to ensure that certain operations are atomic, but this is different than the kind of "barrier" behavior that you were previously describing.1/ Then you have to synchronize even more.
The tradeoff isn't quite like that. I don't have time to dig up the relative core sizes, but the simple answer to your question of how many C-cores to pair with how many fullsize cores is based on the TDP of the CPU and where the all-core clocks of the fullsize cores crosses into the realm where the C-cores offer similar efficiency. We can absolutely work that out, but I don't have time right now.2/ If that was really the case, then instead of 8 fullsize + 6 limited size, you would rather choose 6 fullsize + 10 limited size, then rather than that you would choose 4 fullsize + 14 limited size.
The world is full of pragmatic compromises. We make these compromises to achieve a better outcome than if we stubbornly held to uncompromising positions.The fact that this is not the architecture we observe, mean there is a difference, and that you would prefer to use a full size core rather than several limited size ones.
Hence, there are drawbacks using limited size cores.
The engineering world is ruled by such tradeoffs. What's optimal for one system might not be optimal for another. Numerous parameters have to be tuned, in order to deliver the optimal solution for a given set of constraints or requirements. The mix of core types is ultimately just another one of these tunables.
What makes it challenging is that the concurrency APIs in some modern operating systems haven't caught up (credit to Apple, here) and then applications have to actually use them. That still doesn't make E-cores or C-cores bad, in most cases, but rather just not as good as they could be.