You don't need an abstraction to do something that's natively implemented on your platform.
For example,
$(el).hide()
el.style.display = 'none'
el.hidden = true;
" it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar"
It's easily overridden by CSS.
el.style.display = 'none' pretty much works everywhere.
To me, it seems to depend upon what the purpose of hiding/showing the element is in specific cases.
> el.style.display = 'none'
You meant something more like
document.querySelectorAll(el).forEach(function(e) { e.style.display = 'none'; }
jQuery rarely dumbly duplicates some native functionnality, as for the example above, most of the time it will diverge in meaningful ways.
As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads to me as "spaghetti generator".
I think this is more important than a side note. The reason jQuery's 'children' or 'find' is way better in my eyes is because of the support for arrays as target and argument, and the possibility to pass the resulting collection to the next command as is.
Going the native route, filtering the children will need an extra loop, doing so on an array of parent elements will also bring an other loop. And we'd have to deal with a Nodelist instead of an array. A 2 command jQuery line would be 5 to 10 lines in native code, every time there is some node tree to filter.
Manipulating collections of DOM elements is such a common case that having to deal with loops every time is just tiring, less readable and more prone to basic errors.
In a way I see it as an anti-spaghetti feature. Less boilerplate, shorter, more concise code with clearer intents.
My side note would be that el.querySelectorAll(selector) is versatile, but not as much as the jQuery find. Telling which cases for which browsers would not work with the native function could be some interview question, but that's not the kind of thing I'd like to remember.
document.getElementById('non-existent').classList; // error
$('#non-existent').addClass('yay'); // hidden bug
The sibling comment points out how a function silently failing when given empty value can be deceiptive. I guess your way of seeing it would be also in line with checking valid values before using them.
It's a very sane approach, and it requires more care and attention for each step. I'm not against it, but usually I'm not sure to see a real payoff for very conservative programming in front end DOM manipulation, I tend to prefer taking some performance hit and ignore the nitty gritty details as well as the small errors, as long as it can be recovered at a higher level.