I don't really understand the purpose of _refCount. From what I understand it is always initialized and increased to 1 when we create a new TileGeometry. Am I missing something ?

This comes into play with the caching used in TileBuilder.ts:newTileGeometry. You can see in convertToTile.js:convert that the call to increase the reference count is made on the result of newTileGeometry, which can be either a new TileGeometry or a TileGeometry that was retrieved from the global tile cache.
We need the _refCount to be able to dispose of the cache entry and GPU device memory only when all references to that shared TileGeometry are dropped.

Ok thanks for the explaination, I missed the cached ones. It makes me think that newTileGeometry could be renamed to getTileGeometry, it would be less misleading.
Regarding _refCount, what do you think about leaving it as a number and putting the logic of fn in TileGeometry:dispose directly? That may be easier to follow.

As mentioned in my reply to your other comment about this topic, dispose is an overridden method from THREE.BufferGeometry so we don't have the leeway to change its parameters, which would be needed considering that the custom disposal logic makes use of references to values that ideally shouldn't be kept as additional fields within the class. There might be a better way to do this, but I currently don't see it.

The two issues are to tell the cache that it something must be deleted and to identify the tile to delete. In the current architecture, one way would be to add an id to TileGeometry and dispatch an event in TileGeometry.dispose trapped by the cache.

TileGeometry already inherits from THREE.BufferGeometry, we could use a mixin to get multiple inheritance or have an EventDispatcher field but that's arguably even less readable.
In general, I'd rather avoid relying on events as much as possible: they're an easy solution in a lot of cases, but it's more of a bypass of architecture than anything and they make code flow harder to follow by creating indirection in what should otherwise be simple single-threaded logic, which is at least in part what we're trying to avoid by moving to TS. In an application this would be fine (taking for example the fact that the Godot game engine exposes a similar "signals" system and that works out fine), but for the core internals of a library I believe this is detrimental to maintainability.
Currently, despite the initial surprise of the reference counting code, its locality makes it easy to read and reason about: everything related to the handling of the reference count is in one file and easily fits into a single screen, and changes can be freely made to the cache with only minor changes required in TileGeometry.

I agree that events can hide an architectural flaw, which would indeed be the case here but I think this is also the purpose of this proposed implementation . The question is which one we'd rather have. I think that events would make it easier to read and I proposed that to avoid a too big refactoring but let's give it some thought and see what we do after.

In my opinion, the clean way to go would probably be that the object that takes care of TileGeometry disposal also takes care of removing it from the cache if the tile is not referenced anymore. By looking at the code, I think that tile cache should be stored in TileGeometryLayer instead of TileBuilder and that it should be the responsability of the TileGeometryLayer to remove obsolete tiles from its cache. What do you think ? That would remove the need to store a reference to the whole tile cache in each TileGeometry.

Storing the tile cache in TileGeometryLayer prevents us from reusing tiles between layers, which could lead to a pretty significant increase in memory usage in complex use cases.
The cache can't be stored in TileBuilder either since it's an interface.
After discussing it with @Desplandis we came to the conclusion that the best option would be to create a static alternative constructor for TileGeometry that would return a Proxy over TileGeometry with the caching logic built-in.
As the entire tile generation pipeline is likely to change in the medium term (say, within the next year or so if we don't run into too many issues), we're waiting for that to really kick the current pipeline to the curb and build anew.

Ok, let's discuss it further at that time. Meanwhile, can you add a comment above refCount to explain why it is implemented like this please? (essentially kind of a summary of what we said here, or maybe even a link to this discussion?)