It looks like you’re really trying to understand this system and make it your own.
I believe your insights here are leading more toward the ‘natural’ way of using a JD system. It is indeed about finding the balance between getting things organised, but not making things brittle by categorizing too much up front.
At the core of JD is the ‘no more than 10 options’ principle. There are 10 areas, and in each area there are ten categories. There should be no overlap between their scopes, so that you make two easy decisions in sequence, and then you know you’re in the right place. Then you get the IDs, and the fact that there are only 100 available (usually) means you should think about this category in a way that doesn’t need more than 100 subdivisions!
(there are obviously exceptions. There are provisions for when a domain really does need more IDs, or when an ID really does need subfolders. Usually these exceptions are for things that repeat over time at a high rate. For example: orders and jobs for a business will number more than 100; tickets from an incident management system should use the ticket number from that system as their ID).
But in general, when thinking how to use IDs, think about how to split up this category in less (often much less) than 100 divisions. And you can optionally go even further, as the Life Admin System does, and create sub-groups using the .x0 IDs as headers. I find this interesting, since it again presents you with a choice between ten alternatives.
(This is adding another level as you proposed – the difference is to not then allow 100 sub-ids, but only 9 under each header. Keep it limited! This is about reducing choice, not expanding it.)
Let me apply this to your example of Home being a section within Where I live and how I get around. If you want to provide yourself space up front to be able to enumerate all possible attributes of your Home, then you will run out of IDs very soon. But the IDs are not IDs of attributes of your house. Maybe ID is not a helpful name. Rather, they are buckets to help you navigate in three easy steps to the place you know for sure something new should be filed. Or where you know for sure you will find something you filed earlier. Hence, the Life Admin System has ID’s like 12.11 Official Documents and 12.14 Inventory. Not an ID for each document relating to your house. Not even an ID for each contract for each house you ever rented. Just a single ID. If you put all those contracts in that folder with the date at the front, it’s easy to find them.
From what I can gather about WorkFlowy, it’s an outliner aimed at effortless nesting and branching to avoid breaking the train of your thought. A JDex is different: it’s a stable set of identifiers which you can refer to in your outliner/notetaking app, but equally in your email subject lines … It’s not something you should be expanding or deepening, the point is to build up ‘muscle memory’ for where things are in it, and for that its structure needs to stabilize.