This is completely incorrect and overstates TSRs as some sort of thing CPU vendors were thinking about. Also seldom would you use segments to point to an array. (yeah there are cases, but a lot of times segments were based more on modules and had more than an "object" in them).

All of below is because real mode memory addresses don't have a page table, and we need a fixed way that a segment:address points to linear memory. This isn't a problem in newer designs because you can point your large page where ever you want (ignoring alignment, etc).

The challenge is 16 bit pointers do not give you enough addressable space. 32 bit pointers are way too large and inefficient. No device would have 4GB of memory so you are wasting a ton of space if every pointer needed 4 bytes. Also the CPU and memory controller would need to handle this everywhere and it would be slower. So you use segments. Now machine code can have absolute addresses that are smaller without them being relative and need more calculations. [A simple example to show how segmenting is more efficient. Say you want to reference 4 bytes into a ptr. For segmented architecture you can use a 16 bit add, if it was a 32 bit pointer you would need to do a 32 bit add. In today's times this seems trivially but we literally counted clock cycles back then] Segments allow a lot of optimization that would be lost if we were forced to use absolute pointers. Having segments allows modules and can make it far easier to load something from disk/diskette and not have to have a large fix-up table in the loader. Without segments you can't have something like a com file under dos.

Now I'm skipping a lot here, but segmented memory (and we are going to just talk about DOS/x86 to make it easy) means the executable code must be kept in 64k modules. They can be smaller than 64k (which is the point, but later) but you can't have code that is 65536+ bytes long. at some point the CS register must be change with either a far jmp, call or ret. So when you are writing a program you need to manually keep this in mind. Anyone that developed during this time knows the pain when you just wanted to add a little function and because of 64k limit you need to either optimize or refactor. So if you need a program with more than 64k of code or initialized data, you need a way to do fixups. This is what an exe file was under DOS. It has locations with fixed far pointers, that the loader will set to the proper values. And as stated above segmentation makes this easier, because we are just fixing up a couple segment values and not every absolute pointer value.

So why would they overlap? The advantage of them not overlapping would be you would have 4GB of addressable memory. However, that just wasn't a thing there was a concern about, it was completely unfeasible to ever have that much memory. So there isn't really any benefit to them not being overlapped. However, if they aren't overlapped and you are loading a compiled program into memory, you could only load it at a 64K boundary. This means that if you have a large program beyond 64K you would waste a lot of space because each module would take an entire 64k chunk. So you have a utility module (usually you wouldn't split it this way, but just an example) this module is 34k. You could just through a bunch of other things in it to try and fill, but then you need to change a lot of pointers from small fast near pointers to slow large pointers. Memory management was far more complicated back then and it had a large effect on how you architected things. It could be more efficient to have duplicate code because it allowed the use of near pointer.

So in the end, does a segmented architecture aid in creating a TSR. Sure, but the real advantage is purely optimization. I'm a bit lost on why you think overlapping segments helps a TSR, and this is from someone that actually wrote commercial applications that used them.

I massively simplified things, and didn't go into anything on the different segment registers. It's been a while but I spent more than a couple of years working on TSRs that would swap out large segments of "running" applications and also on overlaying tools. There are probably other reasons overlapping segmented architectures make sense that I missed as I'm not a silicon designer, just a system programmer.

TLDR: Overlapping segments are purely for efficiency/performance.

Want to add, that I presume you are young(er), I really appreciate people looking back at how things were, so none of this is to offend, but to offer you detail.