Google claims an average-case 25-34% decrease in file sizes from JPEG and PNG, so I guess if you have more than ~100K worth of images to serve it would be worth your while, bandwidth-wise (though of course rendering time on the client would go way up).

Rendering memory usage could change, too (most likely upwards). I haven't looked at the source, but I guess this renders to canvas and keeps the uncompressed data around in that canvas. Browsers might opt to uncompress images on the fly when needed.

Your calculation assumes that no browser natively supports WebP but you'd only need to send the .js and rendering time would only go up (noticeably) if the browser didn't support WebP natively so if your audience was 99% Chrome (& Opera & Android4+ & mobile apps that can include the C library etc.) then you'd be much more likely to use this fallback for the other 1% than than if it was 99% IE.

For the current WebP support figures globally it's about 3/10ths and Firefox support could double that to 6/10ths. I wonder if it already makes sense for Wikipedia? I guess it comes down to the cost of double storage/transcode vs bandwidth.

27K is pretty big in the compressed image world - plus, you have to consider the amount of time the JavaScript requires to render WebP (which could instead have been used to transfer a few extra KB of data).

I think it's pretty hard to win this way.