Yep.
> very little processing power
Not really. Those 5 lines are hiding a pretty big chunk of smarts. Simple scale/rotate transformations are an O(n) operation. That's not so bad. However image encoding/decoding is a bit more expensive.
JPEG encoding, for instance, utilizes an O(n*log(n)) frequency analysis algorithm called a Discrete Cosine Transform. Good JPEG encoders will also do some expensive analysis to maximize precision while minimizing size during quantization (edit: though most just use a set of standard quantization matrices). And then there's I/O. It seems fast when you're only processing one image at a time, but to do this as a real-time service for a number of high-traffic websites is very nontrivial.
Scuse me?
JPEG's frequency transform is a set of fixed linear transforms and is always 8x8, so this step is just O(n) of the area of the image. Also, it's not really "a DCT", just any approximation that will look good when run through the approximation of the opposite transform at the other side.
See http://multimedia.cx/eggs/dct-pr/.
The compression steps after are the most difficult, since they have poor ILP and can involve division. But JPEG is really simple, it's not a burden these days.
One interesting part of it is minimizing the memory use of your application, by using the smallest possible ring buffer for pixels rather than keeping the whole image in memory at once.
I must be misunderstanding because resizing an image, rotating it or many other basic operations consists of about 5 lines of .NET code and very little processing power. I imagine it's not any more difficult in other frameworks. I couldn't conceive of offloading that to an external service under just about any use case.
It seems like they plan to offer video editing via SaaS as well which is more valuable, but I would think the transfer time and bandwidth would kill any speed improvement over a massively parallel SaaS video editor as opposed to using a local open source library.