You'll all have noticed that, as yet, there is no open release of implementation code for this, and so you don't see it in any common pixel tools.
The reason is that the approach is perhaps not as simple to decipher as the author, Xenowhirl, would make it appear. He glosses over the logic but doesn't describe the intent, which is more important when documenting an algorithm.
I managed to get Alan Paeth's "A Fast Algorithm for General Raster Rotation" running in about a day -- the shearing approach to rotation is much more amenable to a sane mind than approaching this through direct use of matrix math, or the sample-plot approach which leaves holes. My implementation doesn't do any blending, since the point is to try and avoid anything but the original colours used in the source image (which, AFAICT, is what RotSprite does).
Paeth's approach is not bad and very fast to process, but you will still the get the occasional "toothed jaggies" that are typically seen on aliased rotations (see OP). It is prior to this step that I would need to implement the entirety of something like RotSprite's approach -- the scaling part's already done, but it's the approach to smoothing (aliased smoothing, that is, i.e. no blending of neighbouring pixels) that I need to figure out, and also the approach Xenowhirl takes to resampling the expanded image using offsets, prior to pushing those back into a rotated image.
I think that it's enough to say, "Its been done by someone who wasn't a PhD in computational geometry," so it cannot be that hard to implement an alternative approach with as good or nearly as good results. It's more about recognising where rotated, aliased images tend to go wrong, and using code to fix those errors in the outputted image as a post-processing step. That's what I intend to try as my next step, anyway.