If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware.
If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc. then that is indeed a problem.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD.
I don't see the latter as a project goal, it's just something that enables coreboot to be used in non-libre platforms.
Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project?
Similar points have been made about Linux supporting binary modules. I'm not convinced that conflating the project's openness with that of third-party modules is helpful.
The heading could read something like "Flexible, open source frameworks for
system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology."
Adding the word "framework" somewhere in there could be useful. I'm don't think the rest needs to change, at least not much. The goal is always to provide maximum openness, auditability, and control. The hard part is conveying that one cannot achieve this goal 100% on many platforms (especially in the x86 world).