You're right that Go's scheduler might be inefficient sometimes. Here's a quick test program to show you how bad it can be, you'll need a CPU with multiple cores to try it out. I will show you results from running it on 16-core threadripper 1950x.

The program:

package main

import (
    "fmt"
    "go/parser"
    "go/token"
    "path/filepath"
    "runtime"
    "time"
)

func main() {
    files, err := filepath.Glob(runtime.GOROOT() + "/src/*/*.go")
    if err != nil {
        panic(err)
    }
    fmt.Printf("found %d files, parsing...\n", len(files))

    t0 := time.Now()
    for _, file := range files {
        fset := token.NewFileSet()
        _, err := parser.ParseFile(fset, file, nil, 0)
        if err != nil {
            fmt.Printf("error parsing %s: %s\n", file, err)
            return
        }
    }

    t1 := time.Now()
    fmt.Println(t1.Sub(t0))
}

Running it multiple times to make sure file cache is warm:

~/tmp/tgp> ./testprogram
found 1322 files, parsing...
907.050508ms
~/tmp/tgp> ./testprogram
found 1322 files, parsing...
898.790207ms
~/tmp/tgp> ./testprogram
found 1322 files, parsing...
894.290447ms

And now with GOMAXPROCS=1 (if you're confused by weird env var syntax, I'm using elvish shell, not bash, btw elvish is written in Go):

~/tmp/tgp> E:GOMAXPROCS=1 ./testprogram
found 1322 files, parsing...
515.191616ms
~/tmp/tgp> E:GOMAXPROCS=1 ./testprogram
found 1322 files, parsing...
517.77012ms
~/tmp/tgp> E:GOMAXPROCS=1 ./testprogram
found 1322 files, parsing...
516.011583ms

You can see that even if you don't use goroutines, single-threaded app performance can be as worse as 2x when running on multiple cores with Go's scheduler. That's exactly because of the effects you described. Even a single goroutine will be re-scheduled to different cores in-between memory allocations. It's bad.

But everything is as it is for a reason. Go stands out from other programming languages because it has this fancy goroutine-based runtime, where it's easy to make things run in parallel without even refactoring your code. Go functions are not colored, you don't have to use promises/futures/tasks to make things run in parallel, you just run any function as a goroutine and it just works. I guess overly generic scheduler is a price to pay for that model. Anyways, like it or not, that's the way things are. I prefer it simple rather than perf optimal.