Yes this is correct, precisely for the reasons you've cited. To answer the original question, at a high level, the code that is most natural to start migrating towards Swift Concurrency primitives, is code which already presents an asynchronous interface.
One other thing I'd like to highlight is that not all blocking is bad. If you are blocking on IO, or using an os_unfair_lock for data synchronization purposes in a tight critical section, the blocking here is temporary and therefore, fine. The effect is that you may have reduced throughput on the cooperative thread pool, but you will still be able to make forward progress. The dangerous pattern is when you are blocking on other future work to execute - like when you might be relying on the (NCPU+1)th thread to run some code to unblock the NCPU threads that are blocked on a semaphore.
As such, synchronous interfaces which may block, can be used from async code with caution. However, using async code while presenting a synchronous interface - which is what the original question is trying to do - is really the recipe for trouble. The deadlock problem is the most significant and unrecoverable one but there are other problems as well, like susceptibility to priority inversions which may result in user-visible hangs and glitches.
Faking synchronous behaviour while using something asynchronous under the hood, means that the runtime will not know who is going to unblock the synchronous work and therefore, cannot resolve priority inversion issues.
As we mentioned in our WWDC2017 talk, it is important to use primitives which have a notion of "single ownership" in order for priority inversions to be resolved. Semaphores and condition variables do not have such a notion. See Modernizing Grand Central Dispatch Usage - WWDC17 - Videos - Apple Developer for more detail.
Swift concurrency primitives like actors and tasks fall into the first bucket of single ownership and therefore, are capable of providing priority inversion avoidance support.