Discogs have different guidelines than MusicBrainz, so even with the Discogs importer userscript you will often have to apply some manual clean up to the releases you’re importing (one of the reasons automatic imports are more often than not a bad idea).
MusicBrainz is generally a lot more “machine friendly” than Discogs. Discogs does have an API and it is possible to query Discogs for help with tagging, but they don’t have any way to use, e.g., AcoustIDs to identify recordings or Disc IDs to look up releases/mediums. They also lack several concepts that MusicBrainz has (works, recordings, events) and mosh a collection of others together into their “label” entity (labels, series, places). Several fields that are direct entity properties on MusicBrainz are stored in generic text fields in Discogs (even if they do seem to have standardised how to present them), e.g. release barcodes and artist birthdates.
All of this makes Discogs inferior to MusicBrainz when it comes to digitally “talking about” music, as Discogs simply isn’t capable of the same level of detail that MusicBrainz is. Thus, for software digitally “talking about” music such as audio taggers like Picard, MusicBrainz is just a more expressive data source.
Finally, Picard is hosted by the MetaBrainz Foundation, the same organisation behind MusicBrainz. Picard was and is written with MusicBrainz heavily in mind by developers involved with MusicBrainz’s development as well. So in addition to the technical reasons that Picard is not going to allow using Discogs in place of MusicBrainz, there’s also heavy political reasons that Picard supports the use of MusicBrainz over other data sources (and will continue to do so for the foreseeable future).