The actual value of Ant is that it allows to collaborate with people, integrate with an automated build environment such as Travis/Jenkins/AppVeyor/… and be an enabler for continuous build and delivery:
If you build your project solely on your own in private without having a version control system and without making your sources publicly available for others to see and explore and play with, then indeed Ant or any build tool for that matter is not necessary.
But, once you start collaborating with others, a build tool like Ant becomes a necessity: First, you don’t want to tell people to use Eclipse just when they want to develop and build your project. Some like to use IntelliJ IDEA, some like to use NetBeans.
You want to ensure that no matter which IDE people use, that, whenever they build your project, everyone gets the same outcome/artifact of it.
Second, you want people to understand your project. And with it comes the build configuration. What dependencies does the project have? What Java version does it require? Are there tests being run during build? Are there any platform-dependent build steps? And all those questions.
Third, you want to give people the feeling that your project is not “broken” by assuring them that it builds on a clean machine such as Travis. When we are talking about “continuous build,” which again is only a thing when you are working on a project with others and want quick feedback about build breakers. Next, you can add “continuous delivery,” where you add the “customer” to this feedback cycle. Whenever you check-in a change into your version control system (Git, Svn, …) then a separate build server can pick up on the changes, build your project and deploy/deliver it somewhere.
Build tools like Ant are therefore enablers for all this automation, collaboration and feedback stuff.
But again: Only really necessary when you want to collaborate, automate and have quick feedback.