The aggregate itself needs to be consistent, however related aggregates can be eventually consistent with respect to each other. In fact, eventual consistency is a common paradigm in DDD within distributed scenarios. The aggregate can be thought of as a consistency boundary. This means that an aggregate is defined in terms of what must be consistent rather than being a pure reflection of reality.
As an example, a behavior on an aggregate can publish a domain event which is then published externally. An out of band handler for that event can bring the entire system into a consistent state eventually. Many times, eventual consistency is a perfectly acceptable business constraint, especially since eventual consistency is far more prevalent in reality.
Take a look at Effective Aggregate Design by Vaughn Vernon for more on this.
UPDATE
Eventually consistent redundancy of aggregates should be evaluated on a case by case basis. Some aggregates will be well-suited to conflict resolution, perhaps with natural compensation actions. These types of conflicts will resolve in ways similar to CQRS-style conflicts where compensation actions are be required to bring the system into a consistent state. As in CQRS, the effects of eventual consistency should be discussed with domain experts.