Why is remapping necessary for jumping to bootloader?

[AC.1]

When jumping to bootloader from software for devices such as the stm32l4, why is it necessary to remap system memory to address 0x0000 0000 in address space by calling __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH? On the contrary, the stm32H7 doesn't require this remapping so why can't I jump to system memory without remapping on the stm32l4 (or other stm32s)? I think it has something to do with the dual bank boot mechanism because AN2606 stated that the remapping is only necessary for devices with dual bank boot but I would like to understand what is happening under the hood that requires the remapping.

[MM..1]

I mean is based on how is system code builded. If for code start on addr 0 need remap...

BOOT pins control this remap by hw, but for jump need be controlled in sw.

[AC.1]

But the base address for the linker is 0x8000000 so your code begins at that address. On boot, the Stm32 just aliases it to 0x0000 0000 but I should still be able to access my code at addresses greater than 0x8000000. Also, I should still be able to jump to the bootloader at its address in the address space regardless of whether my code is aliased to 0x0000 0000. I don't see why the system memory (which contains the bootloader) needs to be remapped / aliased to 0x0000 0000.

[Tesla DeLorean]

0x08000000 is the base for FLASH firmware

The default setting for SCB->VTOR on the CMx processors is ZERO, and whilst this might facilitate a vectoring to the natural address for an image, the code would still need to map the VTOR properly if the shadowing at zero isn't present or persistent.

[AC.1]

I see, so remapping / shadowing the system memory's to zero allows the bootloader to account for exceptions and interrupts. Would this mean that the method for jumping to the bootloader with the Stm32H7, found here https://community.st.com/s/article/STM32H7-bootloader-jump-from-application, fails to account for exceptions / interrupts?