Why the most dominant programming languages didn't follow CSP thread model? I was trying to ask this question in StackOverflow, but later realized that this question is more relevant to general computer science, not specific engineering problems. If you think it's not, please let me know.

Recently I've found out what CSP(Communicating Sequential Processes) is.
According to the article Bell Labs and CSP Threads:

Most computer science undergraduates are forced to read Andrew Birrell's “An Introduction to Programming with Threads.” The SRC threads model is the one used by most thread packages currently available. The problem with all of these is that they are too low-level. Unlike the communication primitive provided by Hoare, the primitives in the SRC-style threading module must be combined with other techniques, usually shared memory, in order to be used effectively...

Another article Share memory by communicating from Golang blog says:

Traditional threading models (commonly used when writing Java, C++, and Python programs, for example) require the programmer to communicate between threads using shared memory (...)
Go's concurrency primitives - goroutines and channels - provide an elegant and distinct means of structuring concurrent software. (These concepts have an interesting history that begins with C. A. R. Hoare's Communicating Sequential Processes.)

Based on what I've seen so far, because Hoare proposed CSP in 1978, it seems that there was no reason to use SRC thread model in programming languages ​​like C++(1985), Java(1995) or Python(1990).
So my question is, why the most dominant programming languages didn't follow Hoare's thread model?
Here's my guesses:

Most programmers back then didn't know about Hoare's thread model.
Most programmers are used to traditional thread model.

What do you think?
There are many approaches for concurrency, with different tradeoffs.  We have threads with shared mutable state (e.g., SRC-style threading).  We have coroutines (like Go).  We have actor models with independent processes communicating via message passing (like Erlang or E).

I would put CSP on a different level.  It's not the same sort of thing.  The form of CSP that I am familiar with is a mathematical, theoretical formalism that can be used to model concurrent systems.  It's not really a model of programming that can be directly used in programming languages.  It's more like the lambda calculus.  You can build programming language APIs inspired by CSP, just like Lisp and Scheme are inspired by the lambda calculus, but it's not directly a design of a thread API itself.

Why did early languages choose to follow the SRC model rather than something inspired by CSP?  Well, all I can share with you is speculation.  The SRC model is a low-level model that maps pretty closely to the primitives provided by processors: it is a thin level of abstraction over that.  Just like C is a thin layer over assembly language (and doesn't use, say, functional or declarative paradigms), it's not surprising that early languages would provide a thin layer over processor primitives (rather than, say, other theoretical paradigms).  Also, the SRC model works well with existing code and existing programming languages.  You can take existing sequential code and then add threads.  When you're writing threaded code, the sequential part of the computation looks just like code written for a non-threaded language.  That backwards compatibility and familiarity was probably significant.  The SRC model could be deployed as a library, without requiring changes to programming language syntax or compilers.  I have to imagine that might have been a significant factor in its adoption.  Also, the SRC model is somewhat similar in many ways to existing Unix primitives for running code in parallel in multiple processes, which I imagine might also have been beneficial for adoption.  This is just my speculation.  Perhaps someone else will be able to provide a more researched answer.