Can the PostScript language be used to fully replace TeX?
PostScript and TeX are designed for different purposes and for this reason one would never exchange one for the other as a replacement. However, from a purely theoretical point of view, both are Turing-complete languages and therefore anything that could be expressed in TeX could be also expressed in PostScript and vice versa.
That aside, PostScript is designed as a page description language and TeX as a typesetting system (or language). PostScript deals with lines, characters, rotation of a coordination system, scaling and colors whereas TeX deals with paragraphs, macros to define a markup language and generally provides many high-level services that PostScript hasn't built in: line breaking, hyphenation, breaking paragraphs into pages, footnotes, typesetting of math. Hence, PostScript is much more low level and indeed is one of the target languages for TeX engines: TeX is compiled to PostScript code (via dvips) or to PDF which can be considered a subset of PostScript.
There have been many attempts to use Postscript's programming power to implement a fuller document-production environment. AFAIK they all fall short of TeX's line-fitting abilities.
The most basic is the typewriter emulator from the Postscript Tutorial (Blue Book), which is then extended in the later Reid books (the Green Book and Thinking In Postscript) to handle embedded control-codes for font changes. These ones operate by reinterpreting the program stream, so I often call them "protocol-prolog" style.
Another style is to implement a set of commands with short mnemonic names and implement the document in the RPN syntax. Examples include the Gonzo Tools, Practical Postscript. This is also the primary technique for designing the output for a postscript driver. (The Green Book and Thinking in PostScript are also good resources for this avenue.)
A hybrid of the above approaches is illustrated by Anastigmatix's tools which even implement the Knuth-Liang hyphenation algorithm.
Not as powerful as Anastigmatix's tools, but stealing as many of his ideas as I could, my own effort (disclosure: it's also my resume, nudge nudge.) includes a combination of the above approaches, with a set of mnemonic procedures and embedded control-codes (including arbitrary postscript code) in the strings which contain the text. Edit: A more complete program of mine is available for review on codereview.se. As predicted, it too falls short of tex's line-fitting capability.
On the other end of the issue is capturing the drawing output as a flattened ps document. The traditional tool for this is still.ps (in some sense, still.ps is to Distiller what cfront was to a native C++ compiler, by supplementing and extending the existing programmability (the ps interpreter on the one hand, the c compiler on the other). not really going anywhere with this, but I find it interesting). With ghostscript's -sDEVICE=ps2write (and sDEVICE=pdfwrite) still.ps is largely unnecessary nowadays, but it remains a goldmine of postscript programming idioms and style.
One other notable example is Julian Wiseman's code for creating Wine-tasting placemats. It is a large, heavily customizable postscript "document" which defines many layout choices.