At least, private documents the fact that the field or method is supposed to be internal and that it's better to avoid using it directly unless you have no other choice.
I'm not saying that Groovy should not honor private modifiers semantics, I'm just saying that it's not a big deal, since there are always options, and easy ones, to bypass it. So it's definitely not a critical issue IMHO. The compiler could produce warnings, for example, that's already one level. You can ask it to throw errors only if you are using static type checking, because there's no way to know at compile time if a field is private or not. At runtime, using a new MOP, we could also enforce the semantics, but if you make it an option to be able to use private fields or not, then you are just making it a little more complicated to use that "feature", but you're still not enforcing anything.
Last but not least, this "feature" is probably used in a lot of Groovy programs, so enforcing the semantics by default would probably break a lot of code.
So, in the end, whatever we decide, we have to keep all this in mind.