typeof allows to distinguish between functions and non-functions, and is indeed the only way to do that reliably, although the Type abstract operation does not. That means that your new operator would not make typeof obsolete.
The two object kinds that I most often want to distinguish are functions and arrays, so that I suggest to add the following two cases:
"array" (currently testable through Array.isArray())
Just found this, because I was wanting to propose a similar idea. It's a shame we have an operator like typeof that's so broken, and no hopeful replacement for it on the horizon. We can't fix old broken features, but we can at least provide good replacements for this, and configure linter rules to prevent us from using the old ones. I also don't see any particular reason to make this an operator, we should be able to simply provide a globally available function, which I'll just call getType().
I do like the table that @ExE-Boss originally proposed. I would be against dividing "object" up into both "object" and "function". Doing so would mean that getType(value) === 'object' isn't checking if the value is an object, instead, it's checking if the value is a non-function object which is not the same thing. If we want to satisfy @claudepache's desire to distinguish arrays, functions, and other "regular" objects, perhaps we could do so by having getType() itself return an object, like this:
Something like that would work too, and it would satisfy @ljharb's concern about robust code not being able to use it.
As a minor issue: it's easier to paint a "typeof is bad" label if the replacement functionality doesn't look like a different form of the typeof operator. In practice, I don't think this would matter that much. But, based on what I've seen in the pattern matching proposal, and how "it can't look anything like switch, because we want people to stop using switch", It's possible that similar logic would need to apply here.