I think the issue starts when xyz new tool requires you to write code specific to that thing, which is something I avoid as much as possible. IMO they should strive to stay out of the way as much as possible and just bundle/optimize/tree-shake and not worry about extending JS as a language or nodejs as a runtime or doubling as a build tool or a filewatcher or a development server etc etc (see the UNIX philosophy 'do one thing well'), even at the expense of less optimal/fast builds. As soon as you start doing stuff like importing your images into your javascript so your bundler can do compiler tricks, you're painting yourself into the corner.
One recent offering I enjoyed working with was esbuild, as I could use it's CLI as part of my existing build system incrementally instead of planning my whole system around it.
4. Does it have limitations that are too restrictive?
5. Does it cause bugs/issues that are difficult to resolve?
The ideal tool just does its thing, doesn't need any code written or configuration, works no matter what other tooling you're using, has no limitations, and will never itself cause a bug.
That might not be realistic to do 100%, but I think it's what all tools should be aiming for.
One recent offering I enjoyed working with was esbuild, as I could use it's CLI as part of my existing build system incrementally instead of planning my whole system around it.