I do think that in practice with APIs like this there's almost always a primary closure that's natural to write without a label: the primary completion handler in contrast to the error handler, the main contents in contrast to header/footer contents, or something along those lines. For example, with that Section API, if you didn't provide header/footer contents you'd absolutely expect to just write the contents in an unlabeled trailing closure. It's a bit odd to have to go back and put a label on that closure just because a header or footer is added afterwards; we don't generally expect adding arguments to disturb earlier arguments. So I think there's an abstract appeal to labeling all the closures — certainly it was my first instinct — that might not match reality very well.
It's also worth pointing out that, if lived experience shows that labelling the first closure is really valuable for a class of APIs, that will be a very straightforward future extension.