What it speaks about a "coloring" of the call context!
BLUE => Blocking I/O call context.
RED => Async I/O call context.
And calling a function which expects a blocking I/O call context in a function running under a Async I/O call context (or the other way around) is sub-optimal.
Depending on the language this can cause anything from it works fine over performance problems and increased likelihood of dead locks to compiler errors or even super nasty runtime bugs.
The important part is it's 100% language depended. But people use arguments like "that's colored so it's bad" (because of the color) or "that has a different color so you can't call it here" (because of the color). Even through it might very well not be bad that it's colored and you might very well be perfectly fine calling that there even through it has a different color then the calling function.
I.e. people use the argument in the same way people argue that static typing is fundamentally bad because there is some language where it brings more drawbacks then benefits.
What's the point of using a type system if "color" is not a feature?
It eases maintenance and working as a team.
And regarding complains about requiring to add or removing await everywhere, this is equivalent to saying "you shouldn't tell everyone that your proc can suspend and all assumptions about the real control flow are off".