I'm definitely in the MOIST camp apparently 😅. I'm struggling to understand the point of the composition. If the point is to count down from 3 to 0, then sum the countdown, I'd just do as in the attached composition (but would probably not comment it that much if it wasn't for the task). It does pretty much the same thing, and is by the looks of it a tad bit faster at it. I got <.03333 seconds for the attached comp repeatedly at ideal conditions VS <.050000... seconds in the original. These are based on frame times though, and can be impacted quite a bit by other open windows and overlays so a couple grains of salt is needed for that timer. I did get outliers at .16 and .18 respectively sometimes for both of them.
I use node naming a lot when building my own stuff rather than comments. Trying to make it easily readable/understandable from the nodes and structure itself is less time consuming than excessive commenting. When noodling intensifies, focus on commenting quickly looses its importance. I look at it as a tradeoff between getting things done and getting things done correctly. That can depend on who is paying the bill. If it's a one-off exported app, it doesn't matter much. If it's a repeated task, a commented subcomp is usually better (to then drop into small exports). If I'm the only one that looks under the hood, and I can understand what's going on from node names and colors, I wouldn't care much about comments. If it's for others to see, use and modify - comments are very necessary.
I think these are two (or three perhaps) issues that should not be confused. Time is always time from composition start, not linked to framerate in itself (and framerate/frame-number should never be used to drive animations).
First is the "Fire Periodically" approach. Use a "Divide" node to set the timing - don't enter decimals manually ;). "1" at input A, then your desired framerate as the divisor. In such a workflow, a "Get System Refresh" node or a "Display refresh time" output from a "System Info" node would be beneficial to make "Fire Periodically" nodes more easy to use (Jean Marie). Then it's just a matter of multiplying the output of this node by an integer to get a subdivision that should match up with the system refresh/draw.
Second is excessive event firing in generators/time input compositions. You don't want to link this up to framerate either, but rather limit the incoming triggers to a more suitable rate for the HW you got. To do this; attach an event cable from the "Time" input port to the "Increment" port of a "Count within range" node. Set it to a minimum of 1 and a maximum of 2. Drag the output of this to the "Which" port of a "Select Event out (2)" node, and attach the "Time" input port to the event input of the selector. Now you can use the trigger outputs to drive the composition at half the input rate (you can also play around with increasing the max value to get an in-between rate, but then you will skip frames here and there).
Also when going fullscreen on a retina mac with a shadertoy-shader you are rendering at 4K or whatever the retina displays are. That can be pretty heavy, especially for some of the more experimental stuff done there. Try dividing the Width and Height inputs by 2 if you get these from the input ports/screen info node!
Edit: Framerate is linked to time, but only in the sense that you get the time elapsed from composition start based on which frame you are at
I can add that by default (for a Norwegian install at least), Excel exports CSV files with semicolon which makes them a bit tricky to import for Vuo. Maybe the separator list for the Fetch Table node should be expanded, or replaced by a custom separator instead?
Edit: This is based on a regional setting in the OS, but changing this will break other stuff, so I'd rather not deal with it. I can also see issues with tables exported and sent across different countries.