I think the main use case today is the dom traversal API. It makes operations like "add the 'error' class to all <input> elements in the form" simple:
$('#some-form').find('input').addClass('error')
Obviously you can do this in vanilla JS, but it's more cumbersome so you'll probably end up rewriting your own less complete version of jquery. There is some value to using a well worn library with public documentation that other developers can find/extend instead of a home grown solution.
With that said, I wouldn't use it for a green field project. For sites that require lots of interactivity I would pick a modern front end framework that doesn't require this kind of manual dom traversal (probably phoenix/liveview).
However getElementById() can return null, thus that entire statement can error. In the old days you had to sprinkle your code with if checks when using the DOM API.
If you are requiring that element to be there for your script to work then that error is exactly what you want. Defensive programming is great and all, but sometimes your assumptions have to meet the road anyway and script errors are a perfect way to signal something went wrong (because that's what they are for).
Of course now we have additional defensive programming tools like `?.` and `??` operators.
It depends, if the page is very dynamic the element may or may not be there.
Point is that the DOM API version of the initial jQuery snippet are not equivalent. $() statement does a bit more than that.
This becomes obvious if the requirement are a bit more complex than the example, perhaps we want to chain more expression on at the end, then the DOM API version becomes more convoluted.
This won't throw an error if the form ID changes. Which is to be expected for working on collections. But I don't like this being the default, exactly because of cases like this.
Same thing of course applies to people who throw around the optional chaining operator without thinking to please TS.
Or would apply if one used a single selector here and document.querySelectorAll
The needless chaining here is a typical example of misleading jQuery code though. Looks as if it was there to prevent this issue.
I can't really imagine willingly doing something nontrivial without a reactive framework these days. I'd be all for jQuery if I did want to do that though.
With that said, I wouldn't use it for a green field project. For sites that require lots of interactivity I would pick a modern front end framework that doesn't require this kind of manual dom traversal (probably phoenix/liveview).