If you use semantic versioning in your project — and you should — then you fix bugs in patch releases (e.g. going from v2.4.6 to v2.4.7), and add new features in minor releases (e.g. from v2.4.6 to v2.5.0). These are both unambiguously good things to do: downstream projects that use your project can happily and blindly upgrade to your new versions knowing that everything is compatible and nothing will break.
But when you issue a new major release (e.g. from v2.4.6 to v 3.0.0), that’s because you made an incompatible change. Now the maintainers of downsteam packages have to stop and think and read your release notes before they can be confident whether it’s safe to upgrade, or whether (as with all the various React-related libraries’ major versions) they’re going to have to rewrite their code first. Most often, they won’t have the time or energy to do this for all the many dependencies their project has.
That’s bad, because it means either (if you are diligent) you have to take on the responsibility of maintaining bugfix releases in multiple major versions; or (if you are not) you just leave users of the previous major version high and dry, with no security fixes.
In semantic versioning, minor releases are where you add functionality; major releases are where you take functionality away (or change it, which is the same thing, because you’re taking away the old functionality to provide new). Or, in short, major releases are where you break things.
Breaking things is bad. Don’t do that. Every major release you have to make should be considered a wretched defeat — a failure to maintain the backwards compatibility that you owe your users. The perfect project would stay on version 1.x.y forever.