It's not about the callback at all, the example is poor and the explanation is lacking. In Go, many standard I/O functions use async I/O under the hood. When you call such a function (inside the handler callback, that is), the current goroutine is suspended yielding to other goroutines, so waiting for I/O doesn't block the OS thread inside the request handler. It's basically what you'd do in C# with async/await, except it's implicit and you don't have to mark functions as asynchronous manually. I.e. you write simple synchronous code and Go makes it asynchronous under the hood. There are several disadvantages, though: it's not tunable, and if there's a CGO call (call to a C func) which uses I/O itself it will block an entire worker thread because the Go runtime isn't aware of any of it.
As far as I know, Java's new virtual threads have the same idea.
In the case of a CGO call you could prefix the enclosing function definition with the "go" keyword to manually initiate a new goroutine? Am I understanding this correctly?
Goroutines are multiplexed onto a finite number of OS threads, which is usually a pretty small number. If you launch a new goroutine, a funky CGO call will still block an entire OS thread, it won't change anything as far is blocking is concerned. When all OS threads are blocked the runtime will spawn additional OS threads, so in the worst case it can degenerate to "OS thread per request".
As far as I know, Java's new virtual threads have the same idea.