For sure – a few things. The PTC gives “same-slot unbundling” protection to builders. This is because the builder is not obliged to publish their payload until t=t2, so they can be confident that there has not been an equivocation. For the splitting attack described in the PTC post, with good peering, the builder can have a pretty idea of it they think it is safe to publish their payload because they have t=t1 thru t=t2 to understand what the slot n attesters see. Also from discussions with builders, slot n+1 unbundling is generally much less of a concern b/c the txns can be bound to a specific slot. So even if they decide to publish and the missing slot becomes canonical, at least those txns cannot be used in the next slot.
Additionally, the PTC does protect the builder from the slot n+1 proposer, because if that proposer builds on the empty block, then the PTC votes will be used to override that block and keep the builder payload in place.
Generally speaking, the tradeoff in these ePBS designs is “how much fork-choice weight do we give the builder”. PTC leans far on the side of not giving much fork-choice to the builder, but that is just the example we describe in this post. Other designs, e.g., two-slot or TBHL (described in Why enshrine Proposer-Builder Separation? A viable path to ePBS) give way more builder fork-choice weight. We might well land somewhere in the middle, in which case we feel that sufficient protections are given to the builder without compromising the reorg resilience too much.