This method of only being two levels deep is interesting. If it works, that's great, but there's nothing to stop you from going three if required, e.g. 10.20.30. But keeping everything constrained has value in itself, if only in that it forces you to think in larger discreet chunks.
But there is a good reason why I navigate to news.ycombinator.com and not 209.216.230.240.
For digital resources like URLs or file systems, using numbers as prefixes or primary IDs only makes sense if their ordinal values represent the most important and intuitive way to browse through the hierarchy.
But in most cases, the name rather than the number is the most important thing, and it's very easy to sort or filter by name -- whereas sorting or filtering by number is only useful if there's an inherent ordering (e.g. date modified) to the numbers.
Names can also be difficult if not done correctly / uniformly. For instance, "Category Name", "CategoryName", "category_name", and "category-name" can all return differently through search.
I don't think the key is names vs. numbers vs. whatever else, I think it's more important to pick a system that works for the use case, then define / document / communicate it as wide and loud as possible.
What an opening sentence.
Way back in 2010 or so I published a series of instructions for the 36th Wing that followed this kind of naming/information numbering convention which was frustrating to fit into, but ultimately once you understand the framework it's faster to write.
That isn't to say it isn't confusing and complicated - which happens to everything at scale - simply that this kind of structure for documentation is pretty common and literally battle tested.
[1]https://www.esd.whs.mil/Portals/54/Documents/DD/iss_process/...