There are several rules I use when doing this. They apply to all kinds of things, not just x and y coordinates, but also to search criteria, sets of flags, sets of numeric parameters, and so on.
That said, not everyone uses these principles, and you can often find high quality code that makes other decisions.
Four or more parameters should usually be refactored into objects
If your function takes four or more parameters, you should try to refactor them into objects that group them together.
The reason is that four parameters for a function is usually just plain too much. In a function call, it gets hard to track which arguments are meant for which parameters, especially if some parameters take a default value or are optional.
Lines of code like these are a quite frustrating to see:
SomeMethod(1, null, null, 1, 0)
SomeMethod(1, 1, 1, null, 5)
In languages that support named formal parameters, this is less of an issue. But usually people don't bother to specify the name of a parameter when they don't have to.
Also, if after refactoring you find yourself still facing a function with four or more parameters, you probably have bigger problems.
Sets of 2+ parameters that appear frequently together should be refactored into objects
This case touches on the coordinates case, since in a project that involves coordinates you will usually have to define many functions that take them as parameters.
If these parameters appear so frequently in method calls, there is probably a strong link between them.
Sets of parameters that control extensible functionality should be put into an object
For example, if you have a method such as:
Search(string name, int age, DateTime date, ...)
Where it makes sense for the list of parameters to be extended with the addition of other criteria, then you should put the set of criteria into an object.