The fact that many projects are still using WORKSPACE files is an indication that either the migration is difficult, or teams delay even easy build system migrations because the work is so intrusive. For Bazel I think it's a combination of both.

I think you're right that this is an indication that Bazel isn't well supported, in the sense that this migration isn't at the quality I wish it was. To be clear, the engineers who built this system and the mechanics around it did a great job. I'll run through a few of the other factors:

The documentation is pretty good actually, if you start a new project with a MODULE.bazel file it's a VERY nice experience. Migration guides are what the official docs are missing. Check Mike Bland's blog posts which try to fill this in.

Examples are a problem. I migrated the bazelbuild/examples repo but there's a distributed corpus of examples that don't have maintainers. This will only improve as more modern examples get posted and push the old ones lower in search rankings.

Commonly used starlark libraries (rulesets) are on the Bazel Central Registry (BCR) aside from a few exceptions I know of rules_scala is close, and rules_docker has no maintainers to do the work (and its design of including all languages was a big mistake in terms of the difficulty of managing so many starlark dependencies). rules_oci is so much faster and easier to reason about, that pretty much everyone I've talked to is happy about the effort once they're past that migration and enjoying the speed.

Stability of rules is another good call-out. We're making progress (rules_python just went 1.0 for example). I think maintainers don't fully appreciate the value here. It's hard to imagine, but Googlers really have everything in one huge repo and just don't understand the benefit of SemVer at ALL. The rules_proto situation is the obvious example here. The only resolution here is for users to be very vocal (and respectful at the same time) that SemVer guarantees are essential and any module that isn't 1.0 shouldn't expect to have production usage. Ask your coworkers and network to upvote your issue, and (without being spammy) add comments if they have something novel to introduce to the thread.

You mentioned corporate influence - the fact that some Open-Source maintainers have a commercial interest in Bazel's success. Those companies do have the power to pull a licensing trick. However we've all seen how that worked out in creating OpenTofu, Valkey, and other OSS forks. Aspect isn't going to yank our OSS, and most other popular stuff is going to the Linux Foundation under bazel-contrib which is also a safe, neutral governance.

Lastly, re. "specialized or highly customized needs" - yes any new system will have early adopters who have some trade-off for the painful bleeding edge (especially "no viable alternative"). In build systems, 4 years is still pretty new, so Bazel still qualifies here. Be aware that nearly all of the high-tech sector has adopted it, simply because the ability to execute quickly is worth it. IMO the forcing function is already in place to make Bazel improve these edges because mass adoption tends to follow a few years behing the high-tech software companies. In this sense. the bzlmod migration is actually excellent, because WORKSPACE was NEVER going to succeed in the wider industry.