The big issue you're trying to address with type based segregation isn't so much the leak of uninitialized data, but rather an attacker managing to get the exec

The big issue you're trying to address with type based segregation isn't so much the leak of uninitialized data, but rather an attacker managing to get the executing code to have more than one reference to a single piece of memory, but each reference thinks that memory is a different type. They give an example in the "Type isolation" section where they have two different types, but one has controllable value, and the other has a pointer. In this scenario the attacker has some way to read the time field. What the attacker does is get you to heap allocate a timespec struct, free it but keep the pointer (classic dangling reference), and then get your code to allocate an iovec. Assuming the attacker has done things "right", the iovec that they allocate will be allocated at the address of the timespec that was freed. Now, it's reasonable to believe that the attacker has someway to get the time described by a timespec, so that is what the attacker now does, except now the dangling timespec pointer is pointing to what is actually an iovec, and so the tv_sec field is no longer a real time value, but is actually a pointer. So when the attacker reads that time out, they can convert it back into an address in memory, which gives them the ability to bypass address space randomization. Now, if the attacker has complete control of the tv_sec they can also read arbitrary memory by setting the time on the ostensibly dangling pointer, and then getting the kernel to read values from the iovec. It should be fairly easy to see how separating where different types of object are stored breaks this path - the most the attacker can do with a dangling timespec is point it at a different timespec, ditto for iovec. Obviously this is not some magical Security Is Fixed panacea - the underlying use after free bug is the issue - but it does make actually exploiting that UaF harder. The post references a few other implementations of type segregating allocators, which also have blog posts that may provide some different details (although obviously the core type segregation portions also have a lot of overlap).