I don't fully understand why exactly this is the result.
Blender uses matrices to store the orientation of objects. These matrices can be converted into a different space, and can be easily broken down into parts that correspond to rotation, scale, and location. So to Limit Rotation, for example, Blender breaks down the matrix into rotation components, clamps the values, and then re-creates the full matrix from these new rotation components. Matrices are a convenient way to store orientations, and they're necessary whenever you want to convert between two different coordinate systems, as is often necessary in constraints.
But when a matrix is the combination of rotation and inherited, non-uniform scale, it creates shear:
In this case, the rotation and scale get mixed together in the matrix, and they're not cleanly divisible for Blender to decompose the matrix. And creating the inverse of the matrix, to, say, turn an orientation in one space into a different space, becomes very difficult and slow, whereas it's nearly trivial when we have uniform scale.
To actually damped track something, we'd need to convert between spaces like that:
The parented bone has exactly the same rotation as the unparented bone. But it doesn't point in the same direction, not when considered in world space, because of its inherited scale. So to damped track a target, we'd need to find the position of that target, in the local space of the bone damped tracking it. 45 degrees in the world is not 45 degrees in a non-uniformly scaled space.
Is there a way around this?
In this case, there is, but it's not easy.
If we want to apply some particular rotation to sheared bone or object, we can use drivers. These don't act the same way as constraints-- they act before rotation and scale components are converted into a matrix. So if we wanted the same rotation values as some unscaled bone, we could use a driver to copy the rotation:
Unlike a copy rotation constraint, driving the rotation preserves the inherited scale. For purposes of a damped track constraint, that's not good enough-- even with the same rotation values, we're not pointing the +Y axis at the same position. But it's a start.
But we can get the location of a position in some arbitrary space with a copy location constraint on a parented bone, in world->world, and then read the local position of that bone. Rotation and scale get mixed together with shear, but location remains separable.
After applying visual transform, we can see the bone copying the location of the tail of the unsheared bone is storing its coordinates in its own, scaled space.
Let's instead copy the location of our "real" tracking target. We'll first copy its location, world->world, onto a scaled bone. Then, we'll copy that location, local->local, onto an unscaled bone, and track the modified location with an unscaled bone. Finally, we can use drivers to copy that rotation onto the scaled tracker:
The rotation values to track our modified location are exactly the same as the rotation values to track our real location, in the scaled space. We have created an inverse, for location only, so that we can evaluate the local space position of a world space target, and then turned that location into the proper rotation that we need.
I expect that you'll want to download the file:
