What are the highlights of the main differences between the two tools?
Project structure
Maven prefers a specific project structure: one must commit to doing things The Maven Way. Maven comes with common build steps already configured in a root pom.xml that is normally inherited by all other project pom.xmls.
Ant+Ivy is more open-ended: while it can do a lot, there are only a few basic requirements in terms of project structure or script usage. There are no predetermined build tasks, goals, or processes. Each build.xml is a clean slate (unless including another script, of course).
Orientation
Maven is goal oriented. You do not say "execute this build target" you ask it to "build" or "deploy" and Maven does whatever it needs to do to get there: you say what you want to do.
Ant+Ivy is task oriented. Each task is implementation-defined and custom. You tell it how to do what you want.
Dependency Management
Maven is best-known for automatically handling dependencies. It will download the correct versions while building without any user interaction as long as the repository URLs are properly configured ahead of time.
Ant has no dependency management except for "Java Classpath." Ivy adds dependency management that is a little more tedious than Maven but still automated. The key here is you can choose no dependency management (e.g. "jars included in my distro or checked into source control") or you can outsource it via Ivy. That choice means more flexibility to meet project needs.
Ease of Use
Maven is (in theory) easy to use. Any developer can pick up a Maven project and immediately know where all of the project resources are located and what they are for: this is due to the first point about Maven having a specific way of doing things.
Ant+Ivy may have a steeper learning curve because each project can be different. Different projects may have different ways of accomplishing the same goals.
Extensibility
Maven allows writing plugins and altering its build process. However, it comes out of the box with a root pom.xml that pushes developers toward its predetermined build processes. New goals or build steps require careful thought and extra effort to inject into the build process.
Ant+Ivy also allows writing plugins and new tasks: doing so is quite easy and one can integrate a new task with minimal effort. There are no predetermined goals or targets to shuffle around or to integrate one's new task into.
How did it happen that Apache evolved to create two completely separate sets of tools that are ultimately so similar in purpose?
The first thing to understand is the Apache project is nothing more than an umbrella under which separate, independent projects operate. Different teams work on different projects. While individual developers may work on multiple projects, there is not some overall roadmap that incorporates Ant, Ivy, and Maven.
Ant came first. It was designed to be a Java equivalent of Make. While Make can build Java projects, it is tedious: Make existed to compile a bunch of compilation units separately then link them. The Java way is javac compiles everything in one go, and what we call "linking" really occurs in the guts of the JVM at runtime. Make was not the right tool for the job: a Makefile for Java is basically one or two targets (javac, jar).
Ant added a little bit of structure on top of Make, but did not fundamentally alter the process.
After a while the community came to realize that hunting down jar files was not fun. Furthermore, there was no standard way to compose projects. With no consistency, Java development was a mess. Maven was designed to solve these problems: it would bring a common project structure and automate the hunting down of jar files.
However, Ant was still really useful. Some projects just lend themselves more to the ad-hoc nature of Ant's processes. Some projects are not compiling code. Some projects were old and it was unlikely anyone would "upgrade" them to Maven.
Along comes Ivy: it adds dependency management to Ant, giving projects the best of both worlds. You can keep your legacy scripts, or you highly customized environment, but gain Maven's most important feature: dependency management.
