Actually, from my examination of the paper, I don't know if the result is of even academic interest.
One generic way to factor a value $n$ is to take a function $F$ and define:
for i = 1 to some_upper_limit do
temp = F( n, i )
factor = gcd( temp, n )
if 1 < factor and factor < n
output factor; halt
This will work for any function $F$. In essence, this is what they are doing; they are computing the various polynomial coefficients $a_i$, and checking if those have a factor in common with $n$.
There's nothing wrong with that; however, it does beg the question: is there a reason we would expect that those specific $a_i$ values to yield factors more often than, say, SHA512? Well, looking at the data they provide, it appears that the number of $a_i$ values they test before finding something are about the same size as the factors (which is about what we would expect for a random function), so experimentally, it doesn't do better than SHA512 would be expected to.
Now, their argument behind the algorithm appears to be that, if we were able to get at the coefficients of $(x + a) ^ n \bmod n$, that some of those are likely to yield nontrivial factors; and while that is impractical to evaluate, why don't we evaluate something related. However, they compute the coefficients of $(x + a) ^ n \bmod (x^r - 1, n)$, and I don't see any immediate reason to expect that the additional modulo operation would not mess up the coefficients (especially since the coefficients we'd like to see are not the lower ones, but the ones greater than the smaller prime factor, which is much larger than r).