Зачем нужна такая запись?

Геттеры/сеттеры нужны для добавления возможности полиморфизма при обращении к атрибутам класса.

Если в будущем понадобится добавить дочерний класс, скажем MovingPoint, у которого при получении координат нужно каждый раз производить вычисления, то в случае использования геттеров достаточно переопределить методы getX() и getY() и работать с ним так же как и с обычным Point. Вот так:

Point p1 = new Point(10, 0);
Point p2 = new MovingPoint(20, 0);
. .
if (p1.getX() < p2.getX()) . .
. .

в if'е p1.getX() возвращает значение аттрибута x, а p2.getX() может производить какие-то хитрые вычисления.

Инкапсуляция, доведённая до абсурда. Причём в данном конкретном случае абсолютно бессмысленная. По смыслу полностью эквивалентно
public class Point {
public double x;
public double y;
public Point(double x, double y) {
this.x = x;
this.y = y;
}
}
, но зато автор может с гордостью заявлять, что доступ к данным его класса "защищён".

Это стандартный способ Java-программистов для увеличения исходного текста и замедления программы.
Попробую объяснить, зачем это придумано. Представьте, что этот класс является частью библиотеки, которая используется в разных проектах. В новой версии библиотеки может понадобиться добавить какой-то код в геттеры/сеттреры. Если бы класс не был доступен как часть библиотеки, можно было бы преобразовать поле в свойство (private поле с геттером/сеттером), с заменой по всему проекту, для этого есть инструмент в IDE. Но для библиотеки такая замена недопустима: придётся менять код всех проектов, в которых используется библиотека. И это нежелательно для большого проекта, когда вашим классом пользуются другие программисты. Поэтому все атрибуты сразу оформляют как свойства: на всякий случай и для однообразия.
Но если у вас небольшой проект, и вы уверены, что в геттерах/сеттерах не нужен код, то нет смысла так делать.
Ещё есть фреймворки (библиотеки), ориентированные только на работу с геттерами/сеттерами, а не с полями.

Ненужная хрень как геттеры и сеттеры.
Единственное применение - фреймворки/библиотеки, где это действительно необходимо для удобства.

Стоит их использовать - если есть дополнительные операции во время взятия/присваивания переменной. Иначе - делать публичными переменными и брать их.
Но даже так, лучше назвать метод по другому, а не просто getA()
Например computeAndGetA().

--
Я раньше бездумно использовал их, полагая это нужно и полезно.
А на деле - лишняя морока. Даже используя lombok, где автоматически, во время сборки проекта, собираются геттеры и сеттеры, где указана аннотация Getter/Setter.

--
Когда можно красиво:
a.b = c.d;
а не:
a.setB(c.getD());

--
анализируя огромный проект, натыкаясь на геттеры, можно получить большую дорожку, переходя по классам.

такие классы легко используются для сериализации/десериализации
фактически в Java такое оформление является стандартом соответствуя OOP парадигме
и как следствие хорошим тоном.

К приватным переменным класса можно только через публичные методы обращаться.