Yeah, I think you’re right that stack allocated data can’t be pointed to by the heap. I don’t know what you mean about “the limited ability to pass references to stack allocated objects” though—you can always pass stack allocated references, you just can’t return them (or they will escape to the heap).
A reference can escape not only up, as a return value, but also down, as a function parameter. I'm not sure how sophisticated the static analyzer and inliners are, but escape analysis can only go so far; e.g. stopping at a method call on an interface type for which it cannot discern the concrete implementation. In fact, I believe at least in early Go releases merely passing an object reference as a parameter to a simple leaf function qualified as an escape, forcing a heap allocation.
Note that the decision to force heap allocation is done at compile time, partly because of the semantics of goroutine stack reallocation as the previous poster hinted at. In principle Go could conditionally copy to heap at runtime, but that's just not Go's style of engineering--that's more in the vein of the JVM and similar environments which push more complexity into the runtime rather than compile time. Though maybe it will or has already begun to go down that road.
