How did Linux/xBSD boot before GRUB

The data doesn’t need to be stored in RAM. Pipes block their writers if the readers aren’t there or can’t keep up; under Linux (and most other implementations, I imagine) there’s some buffering but that’s not required. As mentioned by mtraceur and JdeBP (see the latter’s answer), early versions of Unix buffered pipes to disk, and this is how they helped limit memory usage: a processing pipeline could be split up into small programs, each of which would process some data, within the limits of the disk buffers. Small programs take less memory, and the use of pipes meant that processing could be serialised: the first program would run, fill its output buffer, be suspended, then the second program would be scheduled, process the buffer, etc. Modern systems are orders of magnitude larger than the early Unix systems, and can run many pipes in parallel; but for huge amounts of data you’d still see a similar effect (and variants of this kind of technique are used for “big data” processing).

In your example,

sed 'simplesubstitution' file | sort | uniq > file2

sed reads data from file as necessary, then writes it as long as sort is ready to read it; if sort isn’t ready, the write blocks. The data does indeed live in memory eventually, but that’s specific to sort, and sort is prepared to deal with any issues (it will use temporary files it the amount of data to sort is too large).

You can see the blocking behaviour by running

strace seq 1000000 -1 1 | (sleep 120; sort -n)

This produces a fair amount of data and pipes it to a process which isn’t ready to read anything for the first two minutes. You’ll see a number of write operations go through, but very quickly seq will stop and wait for the two minutes to elapse, blocked by the kernel (the write system call waits).

As you can probably imagine, the handover between GRUB and Linux involves some really intricate low-level steps, so there's no room for advanced tracing or logging. Fortunately, that shouldn't be a problem as there's also no room for any extended stalls in that code. You can get a really detailed trace of all the preparatory steps in GRUB by setting the debug environment variable.

It is, however, more likely that whatever delays you see happen after the control is transferred to the Linux kernel. Normally, you can't see the log messages before the console is initialized. Also, as you have noted, all the timestamps are zero until the timekeeping subsystem is initialized, so it is impossible to figure out the timing later.

Fortunately, you can use the earlyprintk boot option to make the kernel actually print the log messages somewhere, so that you can follow them in real time and see where the delay occurs. earlyprintk can be directed to various destinations, but the most relevant for usual (physical) machines will be serial, vga (old-school console), or efi. Make sure that your kernel is built with the appropriate config options (CONFIG_EARLY_PRINTK*).