> Isn't the point of SSR to avoid needing to have the client make additional requests for the first render?

Yes, hence why it was able to call the Go functions directly during SSR, the results of which were bundled with the payload delivered to the client. gRPC played no role during initial render.

If the React app needed more information/updates as the user used the app then the function calls would transparently happen over gRPC instead.

Consider:

    const MyReactComponent = () => {
        const [things, setThings] = useState()
        useEffect(() => {
            // In-memory call to Go GetThings function during SSR render; gRPC call
            // to Go GetThings function when running in the client.
            GetThings().then(setThings)
        }, [])
        return <div>{things}</div>
    }

Architecturally, not a whole lot different to how you might build a SSR React app on Node. The backend was just written in Go instead and that backend had a built-in Javascript runtime to execute the frontend code for SSR purposes.