You get caught in the concrete examples, you need to extract the abstract idea of them, this is dummy code because it's easier to understand. I don't want to give a 100 line method and expect the reader to spend 30 minutes to grasp the example. I will try to answer your questions:
"Why do you need Mapper class at all": you don't need mapper class, but it's a pattern that lets you separate the code and this is very good for reusing, reading, and maintaining your code. I'm sure that there are other ways, but having a constructor is not one of them. This brings me to your second point:
"You can create constructor in Employee with argument EmployeeDTO": this is not cleaner. You are coupling the EmployeeDTO with the Employee. That's a no-no. When you are working on a big project you have more than one DTO for an entity, because you have different ways to show an entity. So imagine you have 5 DTOs. Do you want to have 5 constructors and all the mapping logic to happened in Employee entity class? Not only that, the mapping is not always one-to-one, meaning that sometimes to map a field you need additional business logic and/or calling different methods and classes. You don't want all this logic into the same class, in this case, Employee entity. That's why this is not a good practice and it's not cleaner. Mapper class is a good and clean way to do that. Even when it gets bigger you can separate it into several classes, decoupling the code further. That way you will comply with the Single-responsibility principle. Employee will change only if you need to add additional fields to it and the mapper will change only if you want to add/remove the outside world representation of an entity.
"why do you need DTO" - again you are caught in the concrete example, but overall DTO is a java pattern that is very useful, not only for decoupling reasons but also for security. Even if you have the pattern you described:
A a=new A();
a.setA1(aDTO.getA1())
a.setA2(aDTO.getA2())
Imagine you are having an entity Employee with id and name. You have a GET API that gets the Employee by id and returns it to the FE to display it on the front page. Then you decide to add an additional column to the Employee entity, let say salary. Now everyone knows the salary of every Employee, because the new fields is automatically returned to the FE.
Again, look at this example abstractly. It's a simple example, but if you are working on a big project and this API is called from 50 different places there is no way for you to control it. That's why you need DTO. There are also other reasons, but you can google it.
Overall I don't agree with your comment. Currently, I'm working on a project with around 120 developers, 20 micro-services, and millions of lines of code. We are using those patterns and they work perfectly. And this is not something we come up with, these are patterns used in many java projects.
