Yes, that's a huge caveat to keep in mind. In fact, when I went to test this I mistakingly thought at first that the code was doing a jump to the Main Actor at first because the call site was incidentally the Main Actor too. Maybe what's missing is a way to tell Swift Concurrency that some code should *not* be run on the Main Actor. I think the Swift Forums had some talk around the idea of introducing a @BackgroundActor annotation? I think right now you can do something like that with Task.detached, which won't inherit (I think) the actor isolation context, but the (lack of) inheritance is in any case implicit, so it's a bit confusing to try to know what's running where.
My counterpoint (for Swift Concurrency, at least) is that it's not that different to the "magic" compilers do with all kinds of optimizations, which are sometimes really hard to predict. But maybe some of those details are best left to the computer to figure out, rather than the programmer. I do agree however that some things that the programer definitely should know about are difficult to grasp in Swift Concurrency. An example of this would be, precisely, the question: Could this block a global actor (like the Main Actor)?. That's something that should be immediately clear to the programmer, to avoid having long-running code on the Main Actor, but isn't.
I'd argue that the plan with Swift Concurrency is to make a similar impact to concurrency as Automatic Reference Counting (ARC) did to memory management. There are still a ton of edge cases where it doesn't just work, but maybe in the not so far future we will just annotate what state needs to be protected by specific actors and it'll just work most of the time. IDK, I wasn't even a developer before ARC was introduced, but that's the closest comparison I could think of 
Well, over time you develop a intuition around what's happening underneath, but there are definitely some absurd scenarios at times. I couldn't find it again, but I read quite recently a thread on Twitter where a SwiftUI animation was fixed by adding a .scaleEffect(1.0) to one of the components. Apparently actual Apple engineers were consulted too and that was indeed the way to fix it. That sounds like reciting incantation to me.
