Um, macros are a huge amount of magic. You basically give language design in the hands of users.
The go authors could do what they originally did with generics: only let the compiler/stdlib have macros.
Also, go users have _already_ started parsing comments for magic strings, so it's not like setting an example of using comments is stopping users from doing this crap too.
A macro language which is defined in a clear and consistent way definitely seems less magic than a macro language which has no real definition, other than examples of comments.
The language relies heavily on comments from way way back.
Yeah, it's magic, but not black magic; it's a civilized way of doing things like these.
As a bonus, if you typo the "include_bytes!" macro, as say "includ_bytes", you get a compiler error.
With the go one, if you typo it as "//gp:emebd hello.txt", then you get no compilation error, just an empty string.
If someone compiles your program with an old version of the go compiler, they get no error, just a totally broken program.
Meaningful comments are some of the worst magic you can add to a language IMO.
It's far simpler to reason about compiler-checked preprocessor instructions or macros, both of which are valid alternatives the go team could have added just as easily.