Have you ever really explored the world of semantics to claim static monolithic semantic "lake" is even possible to solve all programming problems? If we take semantic web tech (which is good representative) and lets say OWL2 powers, it's not Turing complete and one needs to build some pragmatics on top of it with rules interpreter.

I agree that backbone can be built as static (or declarative) semantics, but in order to get applications as we know them there is a need for rules. In the problem domain the boundary between generic semantic blocks and domain specific application should be placed somewhere.

That is where Turing complete languages come into play.

There is also another problem, for which OOP is being (rightfully) criticized. It will actually require programmers to become ontology-makers, and, no surprise, it is hard.

All said, in each project, you should try to put as much code as possible into the declarative part ("graph") and apply generic programming as much as possible. (obvious consequence that there will be less bugs.) However, this is not what programmers are taught to do or even how they think...

There is also a lot of buzz about zero/low code, and what I said applies there as well: it is possible for advanced users / ontologists to make the problem domain backbone, but the reality is it's much rarer skill than ability to program in an imperative style.

In that sense I like your comment ("Programmers should ... be working with concepts." - very much my own thought for a couple of decades!), but reality is unfortunately not so favorable.

If you have any arguments on HOW beyond "should be" - will be glad to see.

For the moment however good refactoring IDE capabilities are needed to keep source code DRY / coherent / consistent... unlike just adding/removing RDF triples into/from the store.