Why do people still use Postscript?
From a publishers perspective, I think, the only fundamental reason is legacy software. Postscript has been a long-lasting and broadly accepted standard. Updating the existing tool chains to PDF would require a massive investment.
So I think, it is all about history. There is a great Q&A that discusses the fundamental differences between Postscript (PS) and PDF from a technical perspective: Fundamental differences : PSTricks, TikZ/PGF and others, but misses a bit on the (historical) significance of these technical differences:
Basically, the technical differences are:
- PS is a (Turing-)complete language that permits to defer arbitrary computations to rendering time, that is, when the PS file is used (i.e., printed).
- In PDF, all calculations have be completed when the PDF file is produced.
At its time, the PS model had some clear advantages:
- In the 80s a decent workstation (VAX-11) was able to compute 1.5 million instructions per second (MIPS) and was equipped with maybe 1 MiB of RAM.
Rendering a complete A4 page at 150x150 dpi resolution on such a system was already challenging. Going higher (300x300 or 600x600 dpi) was basically impossible.
However, even at that time, a laser printer was able to print a page with 200x200 dpi or more.
Industrial printing machines used by publishers were already able to cope with much higher resolutions.
By delegating the computational intensive part to use-time, that is, the printing device, PS provided portability between all these devices and made it possible to prepare high-quality documents even on affordable computers. Instead of equipping every workstation with enough RAM and CPU power to render pages at 200x200 dpi (not to speak about the disk sizes and network throughput one needs to store and transfer the resulting documents), it was enough to have one $10,000 laser printer to do the job for the complete department. If the book got professionally published, the $10,000,000 industrial printer could process the same PS document to render it at 1200x1200 dpi.
20 year later, the CPU power and available amount of RAM is 4,000 times higher. Printers featuring a PS raster image processor (RIP), however, are still relatively expensive:
Already in the 90s, "software-RIPs" (e.g., ghostscript) became popular. Ghostscript does all rendering on your computer and thereby makes it possible to print PS documents even on an affordable printer that does not feature a hardware RIP.
By the year 2000, the ordinary PC and network throughput has become so powerful that "software-RIPing" before printing is typically a lot faster than using the printer's built-in RIP – especially when printing complex PS documents.
In the same decade, PDF became popular, so also the importance of PS as the broadly supported standard for printer documents declines.
Postscript is still used as an intermediate document format, since it is a fully fledged programming language allowing you to compute graphics, which PDF doesn't. PDF shows just the result (after some conversions, sometimes called "Distillation") of the computation Postscript is able to do.
The Postscript based PSTricks package is an example that heavily makes use of graphical computation. It can even solve differential equations. And if you have a Postscript printer, it can do these computations for you.
EDIT, to answer Daniels comment:
One feature that makes Postscript the preferred format, in particular for a publisher, is its editability. If, for instance, line art in a document is too faint, the publisher may want to enhance it a bit globally before giving the document to press. This very issue was raised, e. g., in this question.
With Postscript, doubling the line width in the whole document is easily accomplished by putting
userdict /setlinewidth {2 mul systemdict /setlinewidth get exec} put
into the document header.
With PDF such a tweak is much more complicated.
As you've already experienced, there's a tendency for modest-sized ps files to blow up to enormous pdf files. This is because postscript, being a general programming language, has enormous potential for algorithmic compression.
For a simple example, consider a sheet of 5mm graph paper. A pdf would contain the end-points for every line. In postscript, however, this could be accomplished with 2 loops.
Converting backwards, from pdf back to ps, is not capable in general of making use of algorithmic compression. The pdf would have to be analyzed by some really smart AI/expert. The normal conversion is just to represent the same pdf structures with postscript, which tends to be more verbose. Eg. a 32-bit binary integer will take 4 bytes in a pdf, but it will take 1..14 bytes in a (ascii) text representation.