>This is clearly tuned towards y being in PlateCarree...

I agree that this check is geared towards PlateCarree (this was the original implementation strategy). It would be better to use the y_limits property of the CRS instead of a hard coded value.

>Perhaps this could come from the CRS's xlimits and ylimits properties? (and it should handle the possibility that x is out of range and that the original X and Y values may be invalid)

This is actually slightly tricky:
  1.  The input x coordinate could easily have out of range values, for example a longitude of 240 defined on a PlateCarree projection (is this what you meant)?
  2.  How do we deal with points on corners where the new point is out of range in only one direction? Reversing the vector gives us a point that is still out of range but in the other direction... I'd appreciate your thoughts on this.