There are three major problems with external lib references:
Since the closest example we have is gEDA (gschem, lepton), this article uses the design, implementation details and user experiences with gEDA to demonstrate the problem.
Portability in time breaks when an old sheet ext-refers to an old symbol, then the old symbol is updated (fixed, upgraded, extended) in a way that is incompatible with the old sheet. There is no easy way to tell what sheets reference a specific library symbol. Even if all such sheets are mapped, it is very hard to verify that a complex modification doesn't break any of them.
This leads to the situation that only very limited type of modifications could be considered safe on an already published symbol. For example adding a new attribute automatically changes how sheets are interpreted by netlisters, thus changing the computer-readable meaning of old sheets. Or adding graphics only may result in new graphics overlapping with existing graphics or text on old sheets making it unreadable to the human eye. And of course if the pins are not exactly on the same coordinates after a change, connections break. Adding a new pin may cause short circuit or unwanted connection on an old sheet where a net happens to be already drawn at the location of the new pin; there is no safe place for a new pin in an old symbol.
Normally external library references are based on symbol name, like "resistor-1". There can be multiple libraries configured, per system, per user or even per project. There is no guarantee that any symbol name is unique within the scope of multiple library paths. Which means the same sheet with the same external reference easily can fetch a different symbol on a different system, unless configuration is carefully crafted to exclude (or somehow deprioritize) any library not shipped with the project.
It is also possible to to confuse gschem GUI and break new sheets by opening sheets from two different project in one gschem instance.
A safer reference system would require more information to be stored with the symbol reference within the sheet: some sort of library identification, or a globally unique ID of the target symbol that also needs to match beyond symbol name. These extras would then cause other kind of maintenance problems if libs or symbols are renamed or moved or copied or cloned for derivation.
A major benefit of using external lib references is standardization: to make sure all sheets use the same symbol for the same thing. However, this is not trivial, as there can be multiple different libs available, and even a single lib can have different implementations of the same symbol.
Another benefit is being able to fix a symbol centrally. However, it is a double edged sword with very narrow scope (see above).
Finally, a marginal benefit is saving on disk space and memory usage. However the amount of storage saved compared to typical sheet sizes and hardware capabilities in the last 30 years make this benefit almost totally irrelevant.
In the modern world it's almost inevitable that any schematic sheet is shared and viewed or even edited on multiple systems by different users. Sheets are very often published so that random users could open them. This makes the portability question top priority. Portability is best solved without external referencing.
On the other hand, centrally managed fix/upgrade of symbols is easiest with external referencing, but is also possible without.
My personal experience in my won practice and the practice of fellow users around me suggests exploiting the central symbol updating is rare, while the need for portable sheets is frequent. Thus I've decided that the common case is portability, the special case is symbol update.
An important rule of developing efficient software is if you can't keep every case simple then keep the common case simple and move complication to the rare/special cases. To obey that rule, sch-rnd makes creating portable schematics easy and default, while provides tools for upgrading symbols in an existing sheet. Without external references such symbol update is a bit more work for the user, but can be automated. Also that update is considered the rare/special case thus a little extra work there, if it allows us to keep the common case simple, is acceptable.
Sch-rnd (and the cschem data model) supports only two kind of symbols in sheets:
Sch-rnd does not support any kind of external lib reference from sheets, so sch-rnd sheets are always portable.