Was there any equipment which could directly print out the program or data on a stack of punchcards, without first loading the deck into a computer?
No. Such a dedicated device did not exist.
Neither during the time pf punch card processing (pre-electronic computer) nor and even less after electronic computers became a thing. The simple reason is that there was no need to do so that would justify construction of a special purpose machine.
Then again, it depends on your values of 'program', 'directly', 'loading' and 'printing'.
'Printing'
Now, while there is no card reading printer (at least none I know of), there are (alphabetic) interpreters (like the IBM 557), whose purpose was to read a card and print one or two lines (depending on model) onto the very same card.
Also, beside the fact that they could only print 60 characters per line, they as well need to be programmed to do so. A plug board had to be setup defining the print position, for each column read of the card, to be used.
The reason such a specific device as an interpreter was build was the need for automated production of cheques. So all data for a check was punched on a card with a printed on cheque form by the producing tabulator. The resulting stackwas then moved into an interpreter to translate certain fields into human readable print, making it a valid document, banks (in the US) were required by law to accept.
Without Computer
Before the advent of electronic computers there were tabulating machines, especially printing tabulators, of which some could print alphanumeric characters. Then again, a tabulator is the computing instance of that age (*1).
To make them print a card content meant 'writing' (wiring) a program that directed each column of a card input to a corresponding column of the printer output and let it feed after each card (to enable empty lines).
'Loading'
Now, having a program on card(s) means that we talk about electronic stored program computers - so no printing tabulator. In that case there there no way around using a computer. But the program had not to be loaded, but just processed as data.
How it was done
Keep in mind, (360ish) Mainframes were meant to shovel data, so that printing a card stack is like their perfect job description. All it needs is a simple 'read-card;print-line' loop. Each iteration is simply one machine instruction for reading and one for printing plus a conditional branch executing the loop as long as there are cards in the hopper. Setup is usually all static data or maybe one or two move instructions to get it in place.
So it could be done on bare metal with a few preceding cards holding the program and starting the combined stack as a job.
These copy jobs were that essential, that every OS I've seen, even the most primitive, contains built-in routines to do so (*2), usually accessible via a console command, or by having a card with that command preceding the stack. Essentially a cat <punch: >prn:.
Being such a basic task for a mainframe, it wasn't long that a dedicated spool job was added, waiting in the background for a copy (spool) command coming up and executing it at lowest priority level. This became even more handy with tapes and later disks, as now a stack could be read onto tape, freeing up the card reader (which was usually way faster than the printer) for the next stack, while printing took place from tape/disk.
Heck, having a spooler sitting in background and handling print from disk was so integral to (mainframe) computing, that one does not wonder that IBM requested Microsoft to add a print spool to PC-DOS. Where other micros added printer buffers to speed up printing and still stalled when the buffer was filled, IBM simply ported the idea of a disk based spool to PC-DOS. Programs should not print directly, but always print to a file and issue that file to spool to get it done in background.
The only drawback was that this idea was somewhat alien to all the micro-kids: 'What? A service printing files from Disk? What is it good for? Why on earth should I do that when I can access the printer directly? Also, why does DOS not provide temporary files?' (*3). As a result, PRINT did not get the attention it should have, but that's another story.
*1 - Not to mention that basically every computing center that got an electronic computer would throw out all tabulators right away - allone to save cost. And only computing centers with electronic computers would as well have programs on punch cards, as tabulators were programmed by plugboards, not cards.
*2 - Of course a bit more complex than the mentioned program, as the requirement was to copy between vastly different drive, so a lot of setup was required, with the core loop being exactly the same. So three instructions for the loop and maybe 100 for setup :))
*3 - The classic issue with programmers only seeing their own program and the single task at hand - still today.
