The older browsers which shaped jQuery’s design aren’t in use any more but you’re still paying for the code which now largely duplicates built-in features. For example, if I use querySelectorAll I’m using the browser’s native CSS parser and getting a native NodeList back - all of the work is being done in some of the most optimized C++/Rust code in existence. If I use jQuery, there’s a lot of code which has to parse that selector, build data structures, etc. and some of that is working around limitations which haven’t been an issue since IE6 was released. It’s not as bad as a full virtual DOM, there are a lot of smart optimizations there but it’s still running a lot more non-native code & memory which inevitably adds up on a large project. On older devices with less RAM and memory, this is a lot more noticeable - especially if those are Android devices which started at half the equivalent iOS performance when they were new.
The other problem you get is common to a lot of frameworks: it’s good that you can get a lot done but that means you can get s lot further without learning how it works underneath and by then you don’t want to revisit all of that code. This is especially easy to miss when your developers all use fast systems - React 3+ orders of magnitude slower isn’t noticeable on your $5k MacBook Pro but it might be when your grandfather tries to use that site on his 2011 PC, and by then you probably don’t want to do a messy refactoring on a large codebase.
The other problem you get is common to a lot of frameworks: it’s good that you can get a lot done but that means you can get s lot further without learning how it works underneath and by then you don’t want to revisit all of that code. This is especially easy to miss when your developers all use fast systems - React 3+ orders of magnitude slower isn’t noticeable on your $5k MacBook Pro but it might be when your grandfather tries to use that site on his 2011 PC, and by then you probably don’t want to do a messy refactoring on a large codebase.