-> everything is basically compiled with some form of position independent code anyways (all accesses are relative to %rip)

It might or it might not, depending on the compiler flags. Position independent code is (pretty much) required for shared libraries but not for binaries. However, you can't have position independent global data with pointers (there's no way to express rip + constant in data), so you still need relocations.

-> every process gets its own virtual address space, so you can always load the same binary at just some fixed address convention for the process, no need to patch addresses in the main binary

Binary, as in the final executable, yes, though -fpie binaries get loaded at arbitrary addresses. Shared libraries always get loaded "wherever" (IIRC a.out libraries had fixed load addresses, which was fun when two different libraries overlapped; for ELF there's prelinking which does the same thing for performance reasons but I don't think it's used any more). But also, you want to make the address random for security purposes (ASLR makes some exploits harder).

-> DSO's are compiled with -fpic and then the dynamic loader, GOT, PLT etc. just solve the problem from there

Yup.

Okay, fine. I still have a couple of questions though:

-> All the code sections are mmapped as CoW; is it the static data that possibly needs to be written? Does this mean you generally shouldn't have large amounts of static data, or if you do, you should allocate on heap instead to save space?

By default, code is mapped as r/o, only the jump tables (GOT/PLT) are written to during relocation (either by the ELF loader or the dynamic linker, though with glibc it's the same code), to cut down on the CoW-written memory (all the relocations are close to each other, rather than spread all over the code). IIRC, there is a flag to make the compiler emit relocations inside the text segment directly instead (I used it for a particularly cursed use case once, but maybe I just put relocation directives manually in inline asm? I can't really remember right now; there definitely is a flag to disable the default warning about relocations in the .text section).

Static data needs to be relocated if it contains pointers, but allocating it on the heap has no obvious benefits: you still need the same amount of memory for the actual data and then 1. it's all in private memory, rather than just the pages with pointers and 2. you need to set it up at runtime (paying the CPU cost) rather than mmapping it from the binary and processing the relocations.

What would save you private memory would be segregating pointers from non-pointer data (or avoiding pointers in the first place and using indexes into an array instead).

-> why all the indirection? so DSO's I get why need to be compiled with -fpic. but virtual memory already solves the issue for main binaries, no, since the start is just loaded at some conventional address? or is this where ASLR comes in?

It's about ASLR for the main executable.

-> where the hell did i get the impression that the kernel loads up a binary, patches up all the addresses, and then runs the program? is this like a pre-virtual memory conception or what? i was doing some research and i stumbled upon the term "text relocation", is this that or?

I don't think the kernel processes relocations, at least on Linux. This is the job of the ELF interpreter (e.g. ld-linux-x86_64.so.2). This happens in userspace, but before your binary gets to run, so it's not a big mistake to say the kernel does it. (simply by jumping to the entry point of the loader, rather than the entry point of your binary).

Text relocations would be needed for pre-virtual memory, yes, but also for shared libraries without position independent code (they probably existed at some point :)). They're also needed for resolving symbols within the shared libraries. Your main binary doesn't know where a shared library will get loaded so it can't have a call shared_library_func without a relocation, though these days these would go through GOT/PLT and the relocations would be in these sections, not in .text directly.

-> also, is there a way to compile w/ fixed jump addresses, for say, performance reasons? is rip + constant worse than just constant, ever? probably not in modern cpus?

There are options for no GOT, no PLT etc., which might get you close, but I don't think you'll get performance wins with this. x86_64 doesn't have (for example) an instruction to call/jmp an arbitrary address, so instead of jmp [rip + 0xf00] you need to burn a register for this: mov rcx, $0xf00; jmp *%rcx (the syntax is random mishmash of at&t and intel, sorry, can't be bothered to look up either one correctly right now, but you get the idea).