Some reasons on why we still use them: (1) They're source-control friendly. And (2) in some cases, we could generate them directly from code. We deal with a lot of state machines on embedded devices, and whenever management asks for "documentation", we run a transformer script that consumes the source code and spits out state diagrams that would placate them.
Barring bidirectionality, another possibility could just be to make it easier to integrate Penrose into existing workflows; for instance, if you're writing a LaTeX document then it'd be nice to have a package for Penrose diagrams rather than having to switch back and forth between your LaTeX editing environment and the Penrose editor.
But then, let's say you make a Penrose diagram and you want to tweak it in Illustrator to make it look better, because as you mentioned, the text-based input modality of Penrose is limited. So we could try to make it smoother to export Penrose diagrams to put in Illustrator. You edit the diagram and add it to your LaTeX document. But now, you decide you want to make a tweak to the original diagram by modifying the Penrose source code. This obliterates any changes you made in Illustrator, so now you have to manually repeat the tweaks you already made.
I'm not really sure what the best solution is... it seems hard to have a good workflow story without either being entirely text-based, supporting bidirectionality, or forcing a lot of repetitive manual rework when edits are made.
The promise of text driven diagrams is that you don't spend a lot of time on them. Which is nice. But of course then you run in a brick wall when it's not that nice to look at and you want to fix it and it turns out that there are a lot of things that you just can't do with them.
And of course the real problem is that if it's simple, it probably doesn't need a diagram at all (or it will just state the bleeding obvious). And if it's not simple, the diagram is probably going to be a PITA to get right no matter what tool you use. Especially if you are not sure what the diagram is going to be exactly. These tools are almost universally horrible for sketching stuff out quickly because you get sucked into doing a depth first let's specify everything and the kitchen sink mode. And then you get it wrong and it's a pain to change everything. My brain just works a couple of orders of magnitude faster than most of these tools and I get frustrated with just spending ages on the stuff I already understand (i.e. the stuff that I already know the design for) vs. the stuff I'm still unsure about (i.e. the hard to diagram stuff). As a design tool these are horrible tools. As a documentation tool they are mostly redundant.
I default to just skip diagramming it entirely. I don't enjoy it. I don't believe in it. I usually have better things to do. I find the output is write only: nobody ever looks at it or appreciates it beyond a "ah cool, we have stuff". I've found extremely few counter examples in my decades long career of diagrams that actually add value and are widely appreciated. It's mostly just endless nonsense of trivial amounts of boxes and arrows connected in mostly unsurprising and obvious ways.
If I need something quick and dirty, whiteboards are much nicer. And you can just take a photo and call it a day. And in my experience, nobody ever looks at those either. Those photos have very little value. You draw something on a whiteboard, you use it as a talking point, and then you wipe the whiteboard. Photo optional. Do it if it makes you feel good. You could spend a lot of time translating those into a pretty diagrams. But that sounds like the kind of monkey work that somebody should automate and that you shouldn't be spending time on.