Why can't each Aggregate Root have its own collections of entities/ARs?

Consider the following context:
A World(Entity) has Continents. A Continent(Entity) has Countries. A
Country has Cities(Entity). Let's for the sake of argument assume there
are invariants involved for each one of the referred entities. As such,
they are not only entities but ARs as well.
Were I asked in a standard OO course to implement the classes that model
the shown text, and I'd write the following:
class World {  String name; //identifies this entity globally 
Set<Continent> continents = new Set<Continent>();  ...}
class Continent {  String name; //identifies the continent uniquely in a
world context  Set<Country> countries = new Set<Country>();    ...}
etc
Using this code is as simple as
Continent europe = new Continent("Europe");europe.addCountry(new
Country("Germany"));europe.addCountry(new Country("Poland"));World world
= new World("Earth");world.addContinent(europe);
Now, from what I've gathered from Eric's and Vernon's book, though, is
that I should replace this kind of design by one in which instead of
having each Entity class have its own collections of child entities, to
have a Repository by Aggregate Root type. I'd then have something of the
like of
class World {  String name; //identifier globally  Set<ContinentId>
continents = new Set<ContinentId>(); //ContinentId is a wrapper of a
string  ...}
class ContinentRepository {  ...}
etc
This IMO raises a couple of issues:
    1. It obscures the code.
    2. Entities transversion stops being possible without using an
outside class (that, or each Entity must either have repositories
injected or have its much needed repositories set as static singletons).
That outside class may either be a Repository or a Domain Service.
    3. Something as simple as adding a Country to a Continent will now
need a Domain Service or a Repository, as Continent doesn't have what it
takes to do the task at hand.
    4. Shouldn't we strive for a architecture-neutral domain
implementation? Just looking at these centralized repositories (instead
of one collection by each entity object instance at runtime) makes me
thing of a database-oriented application.
When first reading about DDD's repositories, I got the impression they
would be nothing more than an abstraction of a collection. But from what
I gather from the examples abounding on the web and on Vernon's book,
they sure seem more like an abstraction of a *singleton* collection. I
call them singleton collections because in reality there is only one per
type on a given system (there's always only a CountryRepository in
memory! Only a ContinentRepository in memory!).
I'm at the moment quite confused on the matter. It almost seems as all
the examples I see regarding DDD are database(sql/nosql)-oriented ,
which is acceptable as that is the norm, but some of us work on "purer"
grounds where no database is involved. What is really the problem with
my initial bit of code?