Selective reification exploits the well-formedness of triple scripts' file format to treat the text of a program bundle like code-as-data-as-code and allows specific classes (or functions, etc.) to be extracted and used by the program reading it. Another way of thinking about it is that while traditional OO allows you to send messages to objects but limits you to that, with triple scripts you can go further still and send messages to the program corpus.
This is made possible because the concatenated t-block format, although not a general purpose container format, is generic enough to encode and link additional payloads, and simple enough to make it trivial to extract the desired blocks (or entire subtrees rooted at some given block(s)), and the restrictions of the triple script dialect guarantee that the definitions in those blocks are (for the most part) free of side effects.
(NB: When we speak of guarantees, this should not be taken to include an general safety guarantee against untrusted inputs. Inaft—see below—is able to use fairly simple processing—that might superficially seem "careless"—only because Inaft operates on its own code, which is a trusted input.)
Inaft (the very first triple script program) uses selective reification to extract helper class definitions from its own bundle and define them in child execution contexts that are otherwise isolated from Inaft's own execution context.
While the work that trplkt's "decompile" command does is superficially similar to the optional extraction step for selective reification, trplkt itself is not said to actually be doing selective reification.
trplkt decompile is just doing a straightforward decomposition—the resulting pieces are never reified (in the execution sense, although they do get written to disk).
Advanced forms of selective reification present a way to treat the entire program as an object and send messages to it (in the sense of Smalltalk message passing). At this point, there is no (known) use of this kind of advanced selective reification, but inspiration and opportunity exists. See 280 North's old Atlas Plugin Tutorial covering an Interface Builder-like tool with inspectors. When sepsis-inspector was in active development, the viewer contract design included static definition (in JSON) of metadata that ultimately needed to yield dynamic behavior. To allow the inspector internals to filter for applicable viewers, viewers have to register their metadata file and use a complicated schema to advertise which kinds of objects the viewer accepts. This was straddling the wrong place in the static/dynamic divide, and could have been made easier if viewers were implemented as concatenated t-block bundles and selective reification were used instead.