Most programming tasks are undemanding, and most programmers have limited skills, so it is a good match for a great deal of routine work. It fits in the same niche as Java, where Java's OO apparatus imposes complications that are superfluous for simple applications, and an actual obstacle in most. So, a language that abandons all that is better in those applications.
Simple tools are not bad except when you need something more. So, my agreement was with the idea in mind of writing Pandoc in Go, which would be madness.
I don't know Pandoc so I'll take your word for it. I'll also agree that there are entire of classes that Go isn't sell suited for, but we'll have to disagree as to whether it's limiting for the types of applications it was created for. I must not be building the same class of application as you are.
It really comes down to whether, while working on a big system, you will discover a necessary task that a language cannot do well. This might be because it lacks a key feature, like bit twiddling operations, first-class functions, or operator overloading. It might be inherently just not fast enough to meet a deadline, or not consistently so. It might not know enough about types to prevent common mistakes, or might lack operations on types needed to direct compilation. It might lack the organizational features needed to make a large system manageable. That doesn't make it a bad language, but would make it an unwise choice for a project that might, as time unfolds, be found to need one or other such quality. Generally, the bigger a project is, the more unexpected requirements surface.
This is where we get to the idea of "dynamic range". A language with a wide dynamic range takes correspondingly long to learn. People skilled in it are harder to find and more expensive to hire, you have fewer of them ready to hand, and those you have are likely to be already busy. Yet, you might need more, and any you have more than earn their keep.