Note: simplified explanation
The relationship between two datums (geographic coordinate reference systems) is not just that they may have different ellipsoids. Differing ellipsoids mean different sizes and shapes. If you treat both datums as being earth-centered (center at 0,0,0 in 3D Cartesian coordinates), and convert between them, you may see latitude and height differences.
However, particularly older GeoCRS aren't earth-centered. It's easiest for me to think of them as attached at the surface and their centers as offset from the earth's center. See this diagram as an example.
When converting between two GeoCRS, you also have to take into account the offsets/rotations/scaling. The EPSG online registry lists one transformation between Anguilla 1957 and WGS 1984. It's applied as arc-second shifts:
latitude: -18"
longitude: +4.4"
This is from Anguilla 1957 to WGS 1984.
One place to find more information on transformation including the equations and worked examples is EPSG's Guidance Note 7-2.
Edit: Including Esri projection engine test values
From WGS84 to Anguilla 1957 using the EPSG:1447 transformation
Input: 18.0N 63.0W
Output: 18.005N 63.0012222222222W
From Anguilla 1957 to the ProjCRS EPSG:2000:
Output: 294014.7725 1990652.6476
If I use the original coordinates instead (no transformation):
Output: 294141.1785 1990098.7974
If I set up a 0,0,0 (same as +wgs84=0,0,0,0,0,0,0) transformation between Anguilla 1957 and WGS84:
Output: 18.00185163527N 63.0W -78.86 m
and this value to EPSG:2000:
Output: 294142.2835 1990303.6444
The first and last test cases differ because the first just changes the CRS info on the data--literally nothing happens. On the last, because we're converting to/from XYZ space, the differences in flattening and size between the two ellipsoids are handled. If you can try to picture it, one ellipsoid is within the other. Even though their semimajor radii are different, there's no way to model it, so the longitude is unchanged. The semiminor axes (or flattening) are also different but the differences it reflected in a different latitude and new ellipsoid height value.
The Y/Northing difference on the no-transformation example may be to different Clarke 1880 definitions. EPSG has Clarke 1880 (RGS). I don't remember which version PROJ4 uses for clrk80.
Disclosure: I'm on the subcommittee that maintains the EPSG registry.
Best Answer
I get no results when I search the GeoServices REST Specification Version 1.0 whitepaper for "transformation".
It looks like Esri exposed IGeometry.Project but not IGeometry5.ProjectEx5 (for REST).
Implementing this would be complicated.
AFAIK there are no WkID's for geotransformations. IGeoTransformation.Name is not an industry standard (?) so using that in an Open spec doesn't seem right. Without a WkID for datum transformations, the parameters of the transformation would need to be sent along with the request.It suspect you might need to write either an SOE or a GP service to do this. (If you want to use REST).
Update
Looks like the SOAP interface exposes geotransformations through its Project method. And there are also WkIds for geotransformations.
Update 2
The ArcGIS REST API for 10.1 has added support for geotransformations in the Project Geometries operation. Unfortunately the GeometryService.ProjectAsync method in the ArcGIS Silverlight API 3.0 does not expose this.