But just in general, don't scoff at technologies just because they're not currently popular: there are a few problems out there that can be fixed really nicely within something like Prolog, Lisp or another seemingly dated language. Admittedly, nowadays there's perhaps too much focus towards using walled gardens, as opposed to piping some data through a few Bash scripts or maybe embedding Lua in a larger executable for some more dynamic functionality.
Of course, those are just some overly general examples, but getting discouraged from a good solution just due to peer pressure isn't exactly optimal. Having technologies that don't have good documentation due to never having been popular in the first place, or that are difficult to run or utilize nowadays, however, is a different story entirely.
Where punch cards would fit into all of that, however, i'm not sure as of yet. :)
In my mind I envisioned in on their desk in the next office over that looked like something out of the movie "Brazil" and machines on the desks during the Central Services scene [0]
You know, after a number of years in the industry, I've largely stopped caring about what others think and wouldn't lose my sleep over it - the best tools are the ones that you're familiar with and that solve your problems.
For me, that's using nano, for someone else that could be vim. I might want to use some of the JetBrains IDEs, use something like Java liberally because of its verbosity and not even scoff at older software like Lazarus/FreePascal in some circumstances (their approach to GUI is still superior to most modern ones). For someone else that could be Visual Studio Code, a language like Python, or generally looking in the direction of the bleeding edge of languages, such as Rust.
As long as you reach your goals, i think it's perfectly reasonable to dismiss peer pressure or criticism, unless it's constructive (like the person who suggested that vim is better for replace operations over slow connections, which was a good point but also something I've never needed).
That said, the author's approach to customizing nano made me appreciate how nice having proper configuration files and options within them is!