A comprehensive list of the SWEBOK's problems would run to tens of thousands of pages, so it will surely never be written. But here's a summary of my own comments in this thread on the topic. I think they cover most of the important aspects.
As its Introduction clearly explains, the SWEBOK is primarily a work of political advocacy. One of its political goals is a particular division of labor in software that has been tried, has failed, and has largely been abandoned, as I explained in https://news.ycombinator.com/item?id=41918800. It also advocates basing that division of labor on a form of credentialism which has also been tried in software and continues to fail, as I explained in https://news.ycombinator.com/item?id=41931336.
As explained in https://news.ycombinator.com/item?id=41907822, the ACM canceled their involvement in the SWEBOK effort in part because they are opposed to this political program, leaving it entirely in the hands of the IEEE. Unfortunately, today's IEEE seemingly lacks the technical competence at an organizational level to avoid publishing utter nonsense through many channels. (Many IEEE members are of course highly knowledgeable, but evidently they aren't the ones in charge.)
As a result, the substantive content of the SWEBOK is also riddled with astoundingly incompetent errors; I dissected a representative paragraph in https://news.ycombinator.com/item?id=41915939, finding 12 serious factual errors in 86 words. As is commonly the case with text written with no concern for veracity, it takes roughly 20 times as much text to correct the errors as it did to make them.
The content of the SWEBOK that actually concerns the engineering of software is not just as error-riddled as the rest of it, but also very limited†, displaced by project-management information, as I showed with a random sampling in https://news.ycombinator.com/item?id=41916612. This focus would represent a major departure from accredited curricula in real engineering‡ fields such as mechanical engineering, chemical engineering, and electrical engineering, as I showed by surveying top university curricula in those fields in https://news.ycombinator.com/item?id=41918011. The SWEBOK represents an attempt to substitute management process for technical knowledge, an approach which is well known not to work. This is what Dijkstra was criticizing about the so-called "software engineering" field 35 years ago in EWD1036, which I linked from the third comment of mine linked above.
(Unlike Dijkstra, I do not think that it is futile to apply an engineering approach to software, but that is not what studying project management is.)
Even within the scope of project management knowledge, the SWEBOK primarily advocates the kinds of management approaches that work well in industries such as mining and civil engineering. However, as I explained in https://news.ycombinator.com/item?id=41914610, fundamental differences between those fields and the engineering of software make those management approaches a recipe for failure in software, even with ample engineering competence.
Engineering is a craft based on science, using formalized theory to navigate tradeoffs to solve problems despite great intellectual difficulty. But, as I explained in https://news.ycombinator.com/item?id=41914332, our current formal theory of software is not strong enough to provide much help with that task. That does not mean that teaching people how to engineer software is hopeless; in that comment I outlined a general approach, and in https://news.ycombinator.com/item?id=41918787 I give more details about the specific things people engineering software need to know, which has relatively little overlap with the SWEBOK. This current state of theoretical knowledge means that you cannot meaningfully assess software engineers' competence by testing their mastery of formal theory, because the formal theory we have is only somewhat relevant to actually engineering software. Instead, you must observe them attempting to engineer some software. That is why credentialism is so especially counterproductive in this field. That would still be a fatal flaw in the SWEBOK even if its content were primarily focused on the actual engineering of software rather than project management.
As I said in https://news.ycombinator.com/item?id=41914444, the health-care equivalent of the approach advocated by the SWEBOK is faith healing; the agricultural equivalent of the approach advocated by the SWEBOK was the Great Leap Forward; and the petroleum-exploration equivalent of the approach advocated by the SWEBOK is dowsing.
______
† "The food here is terrible! And such small portions!"
‡ The engineering of software is real engineering, as Hillel Wayne convincingly demonstrated in https://www.hillelwayne.com/talks/crossover-project/, but this is still a controversial point. So I picked three fields which I hope everyone can agree are real engineering. The "software engineering" that the SWEBOK is about, and that Dijkstra was criticizing, is not the engineering of software and is not in fact engineering at all.