It's certainly done in many places. JsDoc is the biggest example I can think of. But they're all walking the line of "this doesn't have an impact, except when it does".
It being done by the language owners just makes them the ones walking the line.
In practice, the Go language developers carved syntax out of comments, so that a comment is "anything that starts with //, unless the next characters are go:"
If it would make you happier you can imagine this is part of the spec. It wouldn't change much if it was.
https://go.dev/blog/inliner#example-fixing-api-design-flaws
So these comments carry more weight than how those comment annotations might be consumed by optional tools for other languages.
For most of the listed examples, I think the corresponding C annotation would have been "[[deprecated]]", which has been added to the syntax as of C23.
That's why you find it in the comments. That is where tools have found a place to add their own syntax without breaking the Go code.
Absolutely you can do the same in Java. It exists to the exact same degree as it does in Go. I expect it isn't done as often in the Java world because it is much harder to parse Java code so the tools don't get built.
Things like "//go:embed" and "//go:build" very much do change the semantics of source code.
The comments above 'import "C"' containing C function definitions and imports change the compilation of go source code.
The "//go" comments contain a mix of ones that must be respected to compile, to being optional, to being entirely ignorable (like generate and fix).
