It's worth noting, though, that text is a serial or linear way of encoding information through symbols. In that respect it inherits its structure from spoken language. The significant visual aspect of text is the forms of the glyphs. Typographers definitely do interesting visual things with text, but this hardly ever happens in programming language syntax.
On a similar note, I get annoyed when Eugenia Cheng claims that the diagrams of category theory are "visual". They are graphs of nodes and edges, which means that they convey topological information, i.e. they are not images of anything in particular. Category theorists deliberately use only a tiny, restricted set of the possibilities of drawing diagrams. If you try to get a visual artist or designer interested in the diagrams in a category theory book, they are almost certain to tell you that nothing "visual" worth mentioning is happening in those figures.
Visual culture is distinguished by its richness on expressive dimensions that text and category theory diagrams just don't have.
 "Visual representation has always been a strong component of my work in category theory, which is a very visually driven subject: we turn abstract ideas into diagrams and pictures, and then take those pictures seriously and reason with them."
I think I understand what you mean, but I'd say this unbounded "richness" is precisely what you must avoid in a programming language. In a programming language you want constraints, not freedom. Your visual language must convey specific, unambiguous information and not be open to interpretation or confusion. A program is inherently closer to a formula than to art.
As a complete and irrelevant aside: I wouldn't assume visual artists will consider category theory diagrams artistically uninteresting. Artists are an unpredictable bunch, capable of finding beauty in the most unlikely things ;)
Name-dropping category theory via including a diagram in artistic work doesn't mean that the diagram itself is visually relevant. It would essentially be functioning as a sign rather than an image. (Feynman diagrams are a totally different story.)
As far as richness goes: I don't think programming languages have to be austere. "Richness" might be a divisive term to use for it. I just mean high degree of expressiveness. Also, I guess, a high degree of elaboration. A rich type system is not necessarily a dangerously self-indulgent, inconsistent, dangerous one—it might instead be the end result of a rigorous process of elaboration according to strict criteria.