no-misused-promises a sister rule to no-floating-promises, yeah.

• NFP checks "expression statement" locations
• NMP checks "expression" locations

NMP does a few extra checks for obviously wrong code:

const promise1 = Promise.resolve(true);
if (promise2) { // obviously completely incorrect
}

const promise = Promise.resolve({a: ''});
const spread = {...promise}; // obviously completely incorrect

But I assume you're specifically talking about the cases covered by the checksVoidReturn option.
Those checks are essentially enforcing the same thing as NFP, yes - preventing you from passing promises to locations where they are not awaited to ensure that your async work is correctly handled.

Taking one of the examples from the docs:

[1, 2, 3].forEach(async value => {
  await fetch(`/${value}`);
});

This is likely incorrect because the work is un-awaitable and the failures are un-catchable.

In your specific case of setTimeout - sure it's technically completely safe to pass your promise like that. But consider the general purpose case.

For example imagine this:

function loadingWithTimeout(cb: () => void, timeout: number) {
  setTimeout(() => {
    setUiToShowLoading(true);
    cb();
    setUiToShowLoading(false);
  }, timeout);
}

loadingWithTimeout(async () => {
  try {
    await someAsyncOperation();
  } catch {}
}, 100);

By passing an async function where one is not expected you've broken your code - your async operation completed well after the utility expected it to and now your UI has "torn" and in a potentially "undefined" / broken state.

It's not just about error handling - but error handling is a big concern, for sure.

Essentially what you're asking for here is the ability to ignore "infallible promises". However TS (or rather JS as a whole) has no concept of an infallible promise.

So in order for us to encode this we would either need to invent a pattern that can be used to declare it, or we would have to implement analysis that can prove it.
The former is, in a way, a superset of the latter as you wouldn't want to declare a promise as infallible if it isn't actually infallible for obvious reasons.

The issue is that solving the later in the general case involves solving the halting problem - which is an unsolved problem. Put another way - we would need to invent a general-purpose algorithm which can analyse a function body to determine if it's possible for the code to throw an exception.

A similar thing has been asked for for NFP - and we've given the same answer as I'll give now -- we are not going to build such a system. Even solving for a small subset is complicated and difficult given you have to analyse code across function and (usually) module boundaries. It's quite an expensive task to do this.

#8404 is our answer to this - it will allow you to declare a set of type names that should never be reported by NFP. In that way you can do something like this

interface InfalliblePromise<T> extends Promise<T> {}
function infallible(): InfalliblePromise<T> { ... }

// not reported by NFP
infallible();

If there's desire we could also add this option to NMP. But you'd be the first request!