Pareto optimality also implies that multiple designs may exist in a 'draw', where design 1 is better on dimension A, but worse on dimension B, and design 2 flips those. These designs are on a pareto front. Making the trade-offs explicit helps readers of the design document who come along later to choose a different trade-off when it later turns out that the relative importance of the dimensions involved changed.
For example, suppose you are designing a network service to meet some use case. Yes, it needs to meet the use case, but there are other things you care about like simplicity of the code, latency, cost to operate the service, and others.
For any design you propose, there might exist an alternate design that is strictly better by some criteria-maybe it works exactly the same but has much better latency characteristics. If an oracle gave you this design, you might agree it was more optimal and choose to implement it, but I don't think it means you failed if you come up with a (sub-optimal) design that solves the problem within the constraint.