TPL (and PLINQ) raise the level of abstraction. They discourage the use of mutable shared memory and low-level locks. They encourage the use of immutable or thread-safe data structures.
Joe Duffy, who had originally done quite a bit of initial work on the TPL, argues in favor of this paradigm[0] of raising the abstraction level.
I feel like introducing the low-level tools without providing a raised abstraction level may be beneficial in the long run (you need low-level tools to build high-level abstractions), however, without these abstractions I suspect a generation of JS developers will need to re-learn all the multi-threading lessons of the last few decades.
I don't see how TPL discourages the use of mutable shared memory any more so than a simple thread pool. Note: I'm not saying that it's not a higher level of abstraction, only that it's abstraction in a different direction (the one that has nothing to do with sharing or mutability).
I'm not surprised that TPL author discourages mutable shared memory and locks - this is the conclusion to which anyone dealing with concurrency a lot arrives sooner rather than later. But that's orthogonal to TPL design.
Now, PLINQ does attack the whole mutable shared memory thing head-on. But it's a much higher level of abstraction on top of TPL.
Joe Duffy, who had originally done quite a bit of initial work on the TPL, argues in favor of this paradigm[0] of raising the abstraction level.
I feel like introducing the low-level tools without providing a raised abstraction level may be beneficial in the long run (you need low-level tools to build high-level abstractions), however, without these abstractions I suspect a generation of JS developers will need to re-learn all the multi-threading lessons of the last few decades.
[0]: http://joeduffyblog.com/2016/11/30/15-years-of-concurrency/