Your example works but there is a next level. NEW WORDS!
The Japanese have a way of dealing with new words. AN ENTIRE FUCKING NEW ALPHABET! Forget just learning Kanji (Chinese pictorgrams) Japanese students have two more alphabets to learn (Kana) hiragana and katakana, one for japanese stuff and the other for sound and foreign words. Oh and EITHER one of them is larger then the western alphabets even the really screwy ones with lots dots and slashes messing up perfectly fine letters.
Whooo!
And forget about different breeds of cats. How do you signal a list of cats? Two different icons combined? In language I only need to add an s to the word, with icons you just doubled the number of needed icons. How about extinct cat breeds? What is the icon for extinct? A dinosaur? Then what icon do I use for a dinosaur? A skeleton, then how do I signal a dead cat vs an extinct breed? You would need an infinite number of pictographs to express anything complex.
Oh wait, I GET IT, Flow charts. They are graphical... AND they tend to contain lots of text because there is just ONE database symbol so how do I make it clear one is the relational database and the other a key value store? With WORDS because the makers of flowchart programs knew LANGUAGE is more expressive and more versatile, so they created a dozen symbols and relied on TEXT to clarify them.
And it is not that you couldn't create a graphical interface for a programming language. But what about extensions? With a text library I can just add it to my text code and use it. With a graphical programming language any extension needs far more work, not just downloading a text file but an entire library with new pictographs and detailing how they can be used.
A new programming language is already hard enough to develop and get from idea to a usable product. With a text language, all the focus can be on the compiler, text editors exist very old ones can be used. But for a graphical programming tool, you first need to create a complete graphical tool before you can start using it. It is just far more work. Want me to proof it? Create a graphical config tool for for instance samba that supports EACH and EVERY option in full detail. Compare the amount of work needed for that vs sudo vim /etc/samba/smb.conf WHAT option do you think the samba developers choose? Months of work vs seconds. And it is not like Samba developers need a graphical tool, they know their config file.
That is the final problem... who is going to make it? Where is the market? You are looking at a tool that costs far more to develop then a conventional IDE, is less flexible, less up-to-date, less extensible for an audience that can't be bothered or isn't intelligent enough to handle text coding.