PCL and PostScript (PS) are not driver specifications but page description languages (PDL): if your printer supports either of these, the job of the printer driver would be to convert the print job to either PCL or PS.
Both PCL and PS can do high-quality photos. But PCL is actually more efficient with large high-resolution bitmap images, especially when your computer's main processor is much more powerful than the printer's processor (the usual case today). PostScript is at its best with text and vector graphics: it can offload much of the scaling/rendering process to the actual printer, which was useful back when a laser printer alone might have had about as much memory and processing power as the rest of your computer. For vector graphics, PostScript can just transmit the required commands to draw the graphic, and the printer will then reproduce the graphic on its own, using its full native resolution.
The driver would need to take into account the available features of the printer: for example, if parts of the print job reach all the way to the edges of the paper, but the printer requires certain minimum margins at paper edges to which it cannot print, it would need to make decisions whether to scale the entire page to fit, move parts of the job to another page or just cut off the unprintable edges. And sending color data to a printer that can only produce shades of grey is just a waste of time (and network bandwidth, in case of network printers). A PPD (= PostScript Printer Description) file supplies this printer-model-specific information.
Unix/Linux printer drivers are usually not kernel modules: instead, they are just regular user-space programs (or even scripts) that convert the print job sent to their standard input to the appropriate page description language on their standard output. In CUPS terminology, this is known as a filter.
If a locally-connected printer uses a non-standard USB endpoint structure (some cases of "host based printing") or some other special protocol, the driver might include a program that handles the special communication protocol too. In CUPS terminology, this is known as a "port monitor". CUPS includes port monitors for some common cases, but a print driver can supply a customized one.
The print spooler daemon (these days, mostly
cups) has the job of receiving the print job from the user, identifying its format, applying any necessary conversions (by filter programs which might also be called "drivers"), and finally outputting the result to the printer device (optionally using a port monitor tailored to this specific printer model).
CUPS has built-in "generic drivers" to handle most PostScript printers by using PPD files (PostScript Printer Description) to supply the printer-specific details. CUPS also extends the PPD file specification so that non-PostScript printers can also be described by PPD files. In this case, the PPD extensions specify one or more extra programs CUPS should run to convert the print job from one of the formats already known to CUPS to whatever data format the printer will accept.
For your numbered questions:
1.) The most widely-used page description languages like PCL and PS have published specification documents: once upon a time, back when actual paper manuals came with the hardware, the specification book might even have been included with the printer.
Other languages and protocols, like many used with "host-based printers", have been reverse-engineered. Yes, it's been a huge effort.
2.) In https://github.com/apple/cups/tree/master/filter, you'll find the CUPS generic PostScript and raster (= raw bitmap data) drivers. There is also the code for reading PPD files.
3.) See the introductory text of my answer above.
4.) openprinting.org has a huge database of printer models and open-source print driver solutions for them. If an open-source driver solution exists for a particular printer, I would expect to most likely find it - or a link to it - in there.