I saw discussions on GitHub where it was suggested that they refuse to match based on metadata over folder structure because they don't trust people to tag files properly. With my library, it generates multiple album entries per multi-disc album because I have them organized with a subfolder per disc, which not only makes no sense considering when you could easily match on disc number and parent folder, but is also a regression. "Short on developers" is a good excuse for lagging in features, not for poor design/implementation. Finally, relying on non-standard fields for matching is unnecessary and is in line with the "overly opinionated" complaint.
I'd probably use Jellyfin if it got the basics right and lacked a thing or two, or if its opinionated implementation was limited to trivialities like how Plex refuses to use local images not named cover.jpg. But it's too opinionated, too inflexibly, about too many things, and I think its opinions are stupid, so it crosses the line as far as I'm concerned. Doesn't help that the code is convoluted and I couldn't figure out how to make changes to the way it analyzes files easily.
I think my problem was that I used Beets to organise my mp3s a long time ago - maybe 2011. It didn't write the ReleaseGroup because that might not have been present for all albums on MusicBrainz at the time.
It still did a great job and Picard nicely filled in the blanks.