I think that macros we care about should be on that page, not just at that link. However, you should check with tibbs/FPC about whether the definitions/list of macros are an altogether dated concept. When I was there we used those because spec files are just shell scripts. For a sysadmin to become a packager, they just needed to understand a few concepts about the structure of the spec file but otherwise they just put their steps from the command line into the spec.
Defining the macros on the page allowed those users to see how the macro replaced some steps of their manual procedure.
However, that may no longer be the audience of the guidelines. It may be that they're now targeting programmers or packagers who don't have the same intimate relationship to the command line as sysadmin and have a greater comfort learning a domain specific language to do a job.
In that case, perhaps the entire concept of enumerating the macros is unneeded for that target audience. Instead, simply introducing the macros when they're used in the guidelines is enough. Talk to tibbs/FPC about what their thoughts are.
I would not emphasize the use of wheel files as they are not source and from flit's documentation, it doesn't appear that wheels are even central to it (contrast how much wheel is mentioned in its documentation compared to pyproject.tom). Instead I would emphasize flit itself as the build tool which we're using to transform the source into the files on our systems. If there's ever an alternative to flit which builds with wheels as part of that process we'll need new guidelines based on that so using wheel as the prime keyword that people associate with this build process instead of flit is not future proof either.
-Toshio