Through there are mono colored languages.

E.g. go would be mono red.

Normally mono blue languages allow you to "emulate" red contexts using callback's, listeners and similar. So some would argue there are no mono blue languages.

Many of the points (like red being harder to use) are 100% language impl. dependent.

The only think which is generally true about coloring is that mixing colors is a bit harder and sometimes can be sub-optimal for performance. But how much harder depends fully on your programming language and use-case might be negligible. Same is true for performance.

Also the two big problem of mono red languages is that while red has less overhead when a lot of parallelism is involved it has more overhaed if little parallelism is involved. And that interacting with other programs using a FFI conceptually harder. Which can lead to a varying degree of complexity and potentially performance drawbacks. But again how much this matters is again very language and use-case dependent.

All kind of tooling (including type checking) can reduce the drawbacks of either model (but introduces new drawbacks like longer compilation times).

As a side note: Communicating between red and blue functions is only potentially hard when they call each other. In the same way mono-red languages have only problems with external programs if they communicating over a FFI. If things like futures, streams, channels or similar are used (assuming proper implementation) red and blue code can normally communicate just fine, even if run in the same process.