That may be what needs to be tackled with exactly: what coreboot fragmentation is “perceived” here?
I repeat: coreboot is the native initialization code to do basic stuff here. It requires user knowledge to provide such configuration to enable/disable features (including virtualization etc, just like you would do in your BIOS menus) either at build time, or later on through runtime configuration (needs knowledge and tools).
Then, skulls/libreboot/osboot/Heads are “users” of coreboot. Those build systems provide specific coreboot configuration to attain their goals, defining which payload they include, and tweaks to accomplish what they want to accomplish.
Most of those coreboot distributions will pack either Seabios/Grub as their payload. Depending if the user wants to boot windows, the coreboot configuration will need to point to additional binary blobs (vbios) either into coreboot or in the payload. (Read Skulls, they explain it good). Libreboot will obviously not include them, since their goal is to boot open source distributions from a firmware that doesn’t include closed source produced binaries either. Osboot has a more liberal policy, Skulls give you the choice, and Heads boots linux only through kexec calls. That is, Heads is a linux payload, and kexec’ into another linux kernel without any “bootloader”, meaning it reuses linux drivers and tools to not include other tools in the possible attack surface at boot.
So to make sure this is addressed once and for all: as long as coreboot will not distribute default configurations for all the possible use cases out there (they won’t), users need to prepare such configuration (text file) for their use case or rely on configurations provided online, and depending on their use case, will have to follow extensive guides to backup their firmware, extract some blobs, do some cleaning on them if desired, and then put them where coreboot expects them for coreboot build to succeed.
Skulls/libreboot/osboot/heads/1vyrain cannot distribute (host them in their repositories) directly most of the blobs required for legal reasons (blobs redistribution policies being restrictive, project owners could be pursued in justice) but can provide tools, scripts (build systems) and outcome ROMs for their defined use cases (you can download blobs as part of other projects or extract those blobs from online available binaries.) Those projects just to the magic of downloading them and putting them at the expected configuration place.
At the end of the day, from technical perspective, when the build happens, coreboot (either reduced by libreboot so no blobs is on the local drive or full) is used to build the provided board configuration, which states which binary to depend on or not, tweaks to be applied, and produces either the final ROM or parts to be assembled by the coreboot distribution after coreboot built platform corresponding ROM. Then, if coreboot configuration was not telling how to stitch final ROM together, the build system (scripts) will apply the final stitching glue to put all pieces back together (nvramtool, cbfsutil, ifdtool, me_cleaner and more).
The coreboot distributions/build systems exist to hide such details, to produce desired outcome without everybody needing to know those details.
Using coreboot directly is always possible. You coukd build coreboot without blobs today for a x200, without blobs and without microcode update. Would that be exactly an equivalent of libreboot? Maybe/maybe not. Could you use their support channel if something goes wrong? That would be highly impractical since too many variables would be in play to try to find out where things went wrong. This is where distributions play their role: they take upstream code version, use it to produce a supported outcome, and interact upstream if issues are found so the whole ecosystem is benefited.