With regard to
The examples should be at best real use cases.
I think it would be hard to do better than link to an actual article (The Hunting of the Hopf Ring arXiv version, published version) in which I used programmatic ideas in designing and defining the macros used in writing it (NB the paper is joint, but the macro designs were mine).
I'll use the arXiv version since the source can be downloaded from there. Let's take an example: Proposition 2.37 on p17. The source for that reads:
\begin{proposition}
Let \(\dcat\) be a \co{complete} category, \(\Gvcat\) and \(\Gwcat\) varieties
of graded algebras.
There are products
%
\begin{align*}
\GvCGvcat \times \dCGvcat &%
\to \dCGvcat, \\
\mOo{(\GvCGvcat)} \times \dGvcat &%
\to \dGvcat, \\
\GvCGwcat \times \GvCGvcat &%
\to \GvCGwcat,
\end{align*}
%
all compatible with the monoidal structure of \(\GvCGvcat\) and with composition of representable functors.
\noproof
\end{proposition}
The rendered version is:
The key part is the rendering of the macro \GvCGvcat is determined by the letters in its name (in this case, the GvCGv part). When \GvCGvcat is defined, these letters are read and the macro set up accordingly. Lowercase letters refer to actual things and uppercase letters to modifications. Thus \GvCGvcat involves applying the G modifier to v and then following that by the C and G modifications also applied to v. How the v is rendered is a universal choice, so that it is consistent between \GvCGvcat, \Gvcat, and just plain old \vcat. Looking at the rendering, you can see that \vcat produces a \mathcal{V}, while the G modification puts a ^* and the C modification a ^c. A little bit of work goes in to ensure that the result looks nice with the double superscript.
The macro \GvCGvcat is defined by the macro \objelt{GvCGv}{y} in the preamble. This defines not only \GvCGvcat (which incidentally does something different in text mode), but also a load of useful other macros which are used at various points in the text. For example, on the previous page (p16) near the bottom we read:
The source for this paragraph begins:
As before we shall give a description of the product.
A \GvCGvobj[\GvCGvobj] represents a functor
\(\cov{\GvCGvobj} \colon \Gvcat \to \Gvcat\).
Notice how much \GvCGvobj[\GvCGvobj] expands to, and that the outer \GvCGvobj and the inner \GvCGvobj end up as different things.
The point of doing all of this was to achieve consistency throughout the paper (roughly 60 pages) while allowing us (the authors) freedom to change our minds (as we frequently did) as to how things would be rendered. By defining everything in layers, changing the base layer filtered through to the higher layers seamlessly. Note also that in the preamble (well, actually in a style file for ease of maintenance) there are almost 200 calls to the defining \objelt macro (NB the count is done from the version on my computer which may differ from the version on the arXiv).
There are other examples of similar things in that paper. I found this way of defining macros so useful, I used the same or similar scheme in other papers: Comparative Smootheology (arXiv version, published version) and Tall-Wraith Monoids (arXiv version) use exactly the same scheme, then in Yet More Smooth Spaces and Their Smoothly Local Properties (arXiv version) I'd learnt about PGF's OO module and tried using it; my latest version (not available on the web as yet) reimplements it using LaTeX3.
Although it did take time to design this system, and it may well be that the time taken more than compensated for any time saved by using it, it really did help in that it allowed us to truly separate content from style since in the document we could just write the name of the thing and worry about how it would be rendered later. Then, if we didn't like what it looked like, we could change that at a later date and know that the whole document would be consistent (no horrendous search-and-replaces needed).
(As an extreme example, at one point we were undecided as to whether we would write actions on the left or right so built in the ability to swap the entire document from one convention to the other. Fortunately, we realised that that was silly before it got too tangled.)
I think that this is the first time I really programmed a paper. I've since used the programmatic capabilities of (La)TeX many times and in many guises. It's been disallowed by clarification in the comments on the question, but I'm going to sneak in a link to my implementation of Hobby's algorithm and calligraphic library both of which involve more actual programming than, I think, a "normal" LaTeX package generally does. There are others that I could mention, but time and tide have waited long enough ...
calc, run a couple ofbashscripts to produce 2.datfiles, and then usetextmergto loop through the.dat filesto create feedback sheets and address labels. Saves keep writing stuff out when completing end-of-module paperwork.