It's remarkably easy to segfault Go applications with data races. Any object with multiple words (so a slice that's an array pointer, a size, and a capacity. Or a fat pointer with the object pointer and the vtable pointer), can be read in an inconsistent state from two threads which can cause out of bounds reads and writes. And this comes up all the time with how heavily the language encourages concurrency.
It's just difficult to actually exploit because of other considerations that practically add a lot of runtime entropy.
The was for a time a vogue for "zero trust networking" and I'm fond of pointing out that the same thing happened there: people would come up with their own axiomatic derivation of what "zero trust" meant, but in reality it was a term of art meaning "non-Google implementations of BeyondCorp".
Terms of art are kryptonite for message board nerds.
And yeah, we tend to use the PLT definitions when we're talking about literal semantics of programming languages. Nothing in this thread mandates a security focused sub-definition.
And even Rob Pike described Go as "not purely memory safe", in a slide that obviously references this exact data race behavior. https://go.dev/talks/2012/splash.slide#49 They considered this a practical tradeoff for simplicity versus the major managed languages defining what happens during data races in a way that doesn't allow you to break memory safety.
Iny experience, the ultra security focused view isn't what most people think of when they hear memory safety. It's one aspect, but one among many. For instance debugability is much nicer when you can't break the object model and get a nice trace out of the system versus when you're trying to find memory corruption with gdb or something.
That said, even the ISRG definitions I've found don't list protection from exploits. It does include out of bounds memory accesses in what makes a memory unsafe language, which would discount Go. Yes, they explicitly list Go as a memory safe language, but there's a good chance that they simply don't know about this behavior.
As someone who used to freelance in exploit research, the go behavior doesn't seem insurmountable for finding an exploit on its own. Frankly it's all the other ecosystem stuff that makes it harder. The fact that go code has a habit of being deployed multiple times a day, you a lot of times don't have access to the binaries, there's generally no dynamic (on Linux) so you have no relatively stable code to find gadgets in, etc. (Although there are aspects of the language like the relative simplicity of the compiler that do help you in some of those regards).