We probably should have removed ArcGisImageServerTerrainProvider prior to the 1.0 release, because it is unfortunately nearly impossible to actually use. The problem is that ArcGIS image servers can return height data in a number of ways, but none of them really work for our purposes. If the heightmap is returned as a floating point TIFF, web browsers (and therefore Cesium) are unable to decode it. If the heightmap is returned as a PNG or JPG, the heights are discretized to a value from 0-255, creating a lousy terrain representation.
The workaround that ArcGisImageServerTerrainProvider expects (and this is not well documented) is the use of a special proxy. The proxy requests heightmap images from ArcGIS as TIFF files, and then re-encodes them as PNG files to serve to the browser and Cesium. Rather than a simple grayscale PNG like the one ArcGIS produces itself, the transcoding proxy uses the red, green, and blue channels to effectively represent a 24-bit integer. This gives us much more height precision than we get from the standard ArcGIS PNGs.
We used to have a Java-based implementation of this terrain transcoding proxy, but it was removed awhile ago. You can still find it here:
Your best bet is probably to use a different mechanism to get your terrain data into Cesium. The best one in my opinion is STK Terrain Server (http://www.agi.com/products/stk/terrain-server/). It’s fast, reliable, and easy to use, but not free.
Other (free) options are GeoserverTerrainProvider (https://github.com/kaktus40/Cesium-GeoserverTerrainProvider), Cesium Terrain Builder (https://github.com/geo-data/cesium-terrain-builder), and a gdal2tiles.py based tool that has been discussed in the Cesium forum (https://groups.google.com/d/topic/cesium-dev/rBieaEBJHiU/discussion).