Once upon a time (80386 era) most computers had less than 16 MiB of RAM, there were no memory mapped PCI devices, and 1 GiB of space sounded insanely huge (especially for a "temporary kernel" that was only expected to be used until GNU finished their own kernel). Mapping all of the physical RAM into kernel space sounded like a good idea; so that's what happened.
Time passed. Lots of code (device drivers, etc) was written that relied on "all physical RAM mapped into kernel space".
More time passed. PCI came along. Computers with > 1 GiB of RAM came along. Intel added PAE so computers could have almost 64 GiB of RAM. Kernel space was still limited to 1 GiB. The "all physical RAM mapped into kernel space" idea became very broken. However; by this time lots of code relied on "all physical RAM mapped into kernel space". It was too late to fix the root cause of the problem and do memory management properly (see note at the end).
This led to ugly hacks/work-arounds; starting with the "2 GiB/2 GiB split", which wasn't a bad compromise for systems with about 1 GiB of RAM (and didn't help when there's 2 GiB of RAM or more).
The "4 GiB/4 GiB" was the next silly hack. The problem here is that switching from one virtual address space to another is extremely expensive (due to TLB flushing and TLB misses); and to achieve "4 GiB/4 GiB" this had to happen every time the CPU switched from "user space" to "kernel space" (every kernel API call, every IRQ, etc) and every time the CPU switched back (from "kernel space" back to "user space").
The "high memory mapping" stuff is the third attempt at not fixing the actual cause of the problem.
More time passed. Eventually AMD introduced long mode, and kernel could have up to 128 TiB of space. Linux developer rejoiced - 128 TiB of space sounds insanely huge today (when computers typically have less than 128 GiB of RAM), just like 1 GiB of space sounded insanely huge almost 30 years ago. This solves the problem "forever", right?!
For DMA devices that can only use RAM in the first 4 GiB of the physical address space; for "4 GiB/4 GiB" scheme they can transfer data to/from kernel space easily enough. However almost all of that data has to be transferred to/from user space; which means that you still need bounce buffers and the "4 GiB/4 GiB" scheme doesn't help much at all.
IOMMU could've helped to avoid bounce buffers, but back before long mode existed most computers didn't have IOMMUs. Even now Intel doesn't provide it on all their CPUs (in an attempt to make people pay extra for CPUs that don't have features disabled). This means that for the kernel to work correctly on all computers it had to work correctly only computers without IOMMU.
Note: There's actually very little benefit to "all physical RAM mapped into kernel space" approach, because a kernel has no need to access the vast majority of RAM at all. However this approach seems easy to beginners that don't quite understand paging properly (and don't understand how the "powerful tricks" paging is capable of can be used to benefit the kernel just like they're used to benefit processes). Because of this the "all physical RAM mapped into kernel space" is a recurring design mistake among hobbyist kernel/OS developers. Please understand that Linus was a hobbyist kernel developer back when this mistake was made (and it's very easy to overlook this now when you see modern Linux).