Yes, 19111 has a non-mathematical, sloppy use of coordinate for ordinate. The only consistency we could salvage from this mess would be to use ordinate for the single numerical value and tuple for the grouped set of coherent values, deprecating all uses of coordinate. That's probably too radical a move so we are stuck trying to be consistent across less than the whole library. At least within a particular module it's critical to be internally consistent. ISO Geometry, aka 19107, is internally perfectly consistent and matches standard mathematical language so there appears no reason to break that internal consistency to match other specs written by people closer to geodesy than to geometry.
Did you really mean getCoordinateValue*s*() ? That's getting even more confusing.
I don't really buy the "you have to have a class to have a single structure" argument. An array of data is a perfectly acceptable single data structure so getCoordinate(): double seems perfectly clear from that stand point.
That said, if we want to emphasize that we are always returning the data by value and not by reference, we could append "value" to all our method names. To be consistent we start having to rename all methods to get*Value()---it seems easier to state in the javadoc that data elements are passed out by value and not by reference. We need to do this anyhow since we can't really have methods getDirectPositionValue().
So far given the choices, the original modification still seems the best.