Being different does not imply being better or worst. Again, any specify example on how the generated code could be better? (e.g. nullability information, etc...)
one of the main advantages of kiota is that is doesn't assume anything about the API you're consuming, contrary to other generators. This means it'll need to carry more information like the media types etc... in the generated code as opposed to dependencies.
And yes! one reason why TypeScript is not yet "stable" when compared with other languages is because we've spent a great deal of time optimizing for size. One of the many optimizations was to use interfaces over classes whenever possible, and when not, use proxies over actual classes. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This is why for a small set of operations (<100) the added weight of a TypeScript client at runtime is almost negligeable.
For dotnet size matters as well, especially when you consider scenarios like embedded or front end development or large APIs. Similarly, we've spent time optimizing for runtime size.
Kiota allows you to select the operations/APIs you care about for your client application instead of generating the whole API surface. That makes for a more nimble client.
No Azure SDK is generated with Kiota today. Some use Autorest, some are handcrafted. This is mostly because kiota came out after all those SDKs, partly because Autorest assumes REST API conventions from the Azure design guidelines https://azure.github.io/azure-sdk/dotnet_introduction.html
The only set of public SDKs generated by kiota from Microsoft are the Microsoft Graph SDKs.