pull down to refresh

The outcome depends on how much of the hashrate is accepting the offending transactions. If both the majority of the network and the majority of the hashrate is rejecting some transactions, yes, the miners that include those transactions will have a greater delay for their blocks to reach other miners. This delay causes a higher stale rate, so the lenient miners would be more likely to lose blocks to competitors that can propagate blocks quickly.
However, if the majority of the network rejects some type of transactions, but a majority of the hashrate accepts those transactions I would expect the effect to present differently: miners are generally well-connected, and the miners with loser mempool policies would likely all be connected via the subgraph with the loser mempool policies. A miner publishing a block with offending transactions would see it propagated quickly to the majority of the hashrate. Meanwhile the minority of miners not accepting the offending transaction would be the only ones affected by the delay: they would be more likely to still find a competing block when the majority of the hashrate had already switched over to extend the chaintip with the offending transactions. I would argue that in this case, the delay actually helps the majority miners with the loser policy because it causes the stricter minority to waste hashrate, similar to a selfish mining attack.
So in short, yes accepting unpopular transactions hurts your block propagation if both the network and other miners don’t accept them. However, you may also be collecting more transaction fees that may offset the loss to some extent, as the propagation delay we are talking about would cause an effective revenue loss of around 1%.