I am not surprised by this and I'm glad they chose to discontinue it. It was never very good and even to a complete beginner it's nowhere near as easy to use as GDScript. This should free up some development budget for more important features.
Visual scripting has never been very good for general purpose programming in my opinion. They don't really represent continuity in an intuitive way and it gets worse when you're dealing with function with many parameters. Shader graphs are probably the one exception to this because they provide a pseudo debugging facility where you get to see how materials change after different operations.
Visual scripting is very good for expressing high-level logic, especially when there’s some kind of delay involved: this happens, then when it’s done, one or more other things happen.
This sort of thing is much clearer and simpler in a visual language than any kind of callback- or await- hell and the pattern is everywhere in gameplay logic.
The big problem with visual languages is that the toolset needs to be excellent to compare with text-based languages (Blueprint nearly is, Godot’s visual scripting isn’t).
Also it’s a completely different programming paradigm and programmers used to text-based languages tend to HATE them. If you think how many programmers are put off LISP because of the brackets, this is more of a culture shock - and the more experienced a programmer you are, the worse it seems to be.
You see it surface in SCADA/PLCs in the form of Ladder programming and Function Block Diagrams. That said from what I understand industry is trending towards more text based approaches lately.
As an ex-gamedev it was interesting to see the overlap there when getting into a bit more serious automation stuff. Edit/deploy live, visual representation of state(which is where ladder excels) and other things we used to do a lot of in game dev was present, but on physical running hardware connected to other sensors/endpoints.
I haven't used the Godot one but they have something similar in Blender and I find this type of programming really hard to reason on.
An algorithm is supposed to be a sequel of instructions and it is easy to follow in code(you go from top to bottom) but it's hard to follow when represented as if it is a set of pipes going through boxes. Also, the boxes often require specific type that is not compatible with the output from the previous box and you need to create an algorithm for type conversion and that appears as prominent as the actual algorithm that you are trying to create(in code, you can hide the type conversion complexity behind a function, for example) and as a result it's really hard to get "the gist" of the algo when represented in this visual style.
Visual scripting has never been very good for general purpose programming in my opinion. They don't really represent continuity in an intuitive way and it gets worse when you're dealing with function with many parameters. Shader graphs are probably the one exception to this because they provide a pseudo debugging facility where you get to see how materials change after different operations.