As a general policy, blocking operations should not be performed in the scope of a go block, and that includes the core.async blocking operations like >!!. So, yes - the problem here is that the pipeline code violates this policy. In practice, you're correct in this particular case that using >!! on an empty channel of size 1 won't block (but it still violates the policy of intent).
Using put! would be another option, however there is also a bigger conceptual issue here that pipeline purports to use "parallelism n". However, by putting those tasks in go blocks, you are actually subject to a max parallelism of the go thread pool, which is typically 8, and that presumes no one else is using the go block thread pool, so it could even be less than that. And secondly, if the user happens to do a blocking operation in pipeline (which they shouldn't), then they can easily lock up the whole system.
Switching to use the same strategy as pipeline-blocking (using a separate caching thread pool) addresses the parallelism issue. However, this may not be the last change in this regard - we may still switch to use an explicit fixed size compute thread pool, rather than a caching thread pool which would separate these again. So, no plans to deprecate anything - the user is still stating an intent that makes an important difference here.