But of the reasons Books gives, most apply regardless of the project being late, such as the communication overhead and the fact that splitting the project neatly is difficult.
Modern software projects are wildly different than OS/360.
The insights from 50 years ago is fine abstractly but it has its limitations.
Not only are there many more roles to fill but things like translation and QA scale pretty well.
It's an adage, not a hard and fast dogma.
Also it was specifically limited to when in the project people are added and often gets misremembered as some linear programming inspired exercise in optimal team configuration.
The latter is obvious and useful (right size the team for the job) but IIRC, Brooks doesn't actually address it in the famed literature.