The contribution of the paper (to my thinking, at least) is to assume that an attacker can also sybil attack the network, and in doing so can run nodes which will release blocks produced by the attacking miners in response to hearing a new block from the honest miners. So where the sybil attack is successful the delay does not confer a disadvantage and then the attack works (with increasing effectiveness the more effective the sybiling is and the more hashrate the attacker has).
I think it is a little worse than that. An effective Sybil attack is necessary to make the attack viable for a small pool, but the larger the pool is, the less effective the Sybil attack needs to be. For a pool larger than 33% of the network, no Sybil attack is required.
On the other hand, one mitigating factor that is not mentioned in the paper is that the attack buys you more revenue long term, but in the short term you will see a loss of revenue. You are not finding more blocks than before (in fact you are losing some of your blocks) so your income within a difficulty adjustment period will actually drop (but so will everyone else's). The increase in revenue comes later due to the fact that you caused others to lose blocks which makes the difficulty drop (or just rise less than it would have) which then nets you more blocks in the long run.
However, since
a) The attack can easily be detected (sudden increase in orphaned blocks)
b) The attack will negatively affect the bitcoin price.
the revenue impact of performing the attack is probably negative even in the long run.