Looks like we’ve resurrected an old thread, but I’ll chime in anyways 
If you want developers to be stuck with really bloated, slow canisters then I guess this idea makes sense.
Motoko is also garbage collected, so I don’t think that’s a reason why Go would be super bloated or slow. Granted, it won’t be as optimized as Rust or Motoko.
I’m not happy with having Typescript compile to WASM,
If you’re referring to azle, my understanding is that’s not really compiling TypeScript to WASM, it’s a WASM that interprets TypeScript at runtime. Haven’t tried it, but it must be way slower than Rust or Motoko.
I think a great CDK to build would be AssemblyScript. It’s a TypeScript-variant that actually compiles to WASM, so should be way faster than azle. I found this experimental cdk for it from six years ago. I’ve thought about building on that, but I think the future will be serverless and canisterless, and canisters will be a low-level building block only touched by infrastructure developers, so I don’t think it’s really what’s missing. But maybe I’ll build just-in-time canister compilation for my Frosty Functions someday and will need an AssemblyScript CDK as part of that, who knows 
Microsoft recently announcing that they rewrote TypeScript in Go, I had a hunch there might be some momentum in the web dev community to explore it.
That’s only the TypeScript to JavaScript compiler though. I think Go is used a lot for tooling now (e.g. esbuild), but I don’t think the average TypeScript dev ever has to touch Go.