Before attempting to counter argue with me, please try what I suggest.

ECMAScript proposal: Type Annotations

This proposal aims to enable developers to add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript. At runtime, a JavaScript engine ignores them, treating the types as comments.

The aim of this proposal is to enable developers to run programs written in TypeScript... without any need for transpilation, if they stick within a certain reasonably large subset of the language.

Trends in JavaScript Compilation

...
This proposal will reduce the need to have a build step which can make some development set-ups much simpler. Users can simply run the code they wrote.

This is already possible. You just have to write all your types in .ts files and then import them via JSDoc comments in the .js files (do not forget to use "allowJs": true,"checkJs": true,include : ["./**/*.js"] and maxNodeModuleJsDepth in your tsconfig).

Limits of JSDoc Type Annotations

This section of the proposal did not mention importing types from .ts files via JSDoc comments. The section should be extended with this example:

//types.ts
export type IStringsStringStrings = (p1: string, p2?: string, p3?: string, p4? : string, ) => string;

//index.js
/**@type {import("./types").IStringsStringStrings} */
function stringsStringStrings(p1, p2, p3, p4 = "test") {
    // TODO
}

...JSDoc comments only provide a subset of the feature set supported in TypeScript

The question is not whether JS should have types, but rather "how should JS work with types?" One valid answer is that the current ecosystem provides sufficient support where types are stripped out separately ahead-of-time, but this proposal may provide advantages over that approach.

Regarding importing .ts types via JSDoc comments in .js, which are these missing features (when compared to the features of this proposal)?

...JSDoc comments are typically more verbose

You have to type /*@type {}**/ and then the intellisense for importing types will work. It is not that much of a big deal regarding verbosity especially given the fact that like this you avoid the drawbacks of compiling .ts to .js, and also you do not need a new proposal that will make JavaScript parsing slower.

This proposal will require work from both ECMAScript and TypeScript itself, where ECMAScript expands its current syntax, but TypeScript makes certain concessions so that types can fit into that space.

There is no such need when importing types from .ts to .js files via JSDoc comments.

Why not stick to existing JS comment syntax?

Although it is possible to define types in existing JavaScript comments, as Closure and TypeScript's JSDoc mode do, this syntax is much more ... unergonomic.

This is a biased opinion that is not true. With importing types from .ts to .js files via JSDoc comments you can get all the benefits of this proposal without the need to introduce a new proposal and without the need to change existing JavaScript parsers (client or not) and make them slower. Finally forcing separation of abstractions and concretions is a good practice.

Consider the fact that JSDoc type annotations were present in Closure Compiler prior to TypeScript, and that TypeScript's JSDoc support has been present for years now. While types in JSDoc has grown over the years, most type-checked JavaScript is still written in TypeScript files with TypeScript syntax.

Why did TypeScript support writing concretions in .ts files in the first place? That was a major mistake, that further fragmented the ecosystem and added an extra build step. The fact that we did/promoted a mistake in the past is not a valid argument in favor of continuing this mistake in present and future.