Every community is the sum of its members. Each person who joins changes it, at least a bit. And each of those members is changing and growing.
When community members have different needs, forking should be a last resort. It's expensive, and it's wasteful unless two different groups have irreconcilable needs. It should only ever be suggested as a last resort, after other options have been exhausted.
However, it's often used as a first resort to shut down criticism and to protect existing power structures. The person who speaks up is, as here, treated as an outsider and an exploiter.
I imagine with coding agents, maintaining private forks (reapplying patches on upgrade) will be a lot easier. Though, a plugin architecture would be better, where feasible.
If there there's a big enough community swapping patches that upstream isn't accepting for some reason, that's when a public fork becomes reasonable. (This is the Apache web server's origin story.)
I rarely see good faith engagements being immediately shut down with "just fork it" (you'd never accept issues / MRs!). Instead it's usually used as a last resort when the "exploiter" doesn't get their way and starts whining about it.
If a change is proposed that's completely counter to a community's stated values, then I guess "fork it" is a more appropriate immediate response, because it's hard to see how such a clash could be resolved without fundamental change.
Edit
> Every community is the sum of its members
A community is much more than the sum of it's members.