You didn't mention that Prolog doesn't have a proper module system, only an approximation:-)
To the locals many of those warts become invisible. That's why such "outsider" reports are important. Will you do Perl next? :-)

bagof: yes, could be redesigned to be much less confusing!

cuts and non-cuts are confusing: true! :-)
->, *->, !, once(), \+, atom, integer, bagof, ... and many others are all non-logical! Logical alternatives are possible, but less performant. I'd love to have all such constructs prefixed with "dangerous_" or something! But that would break compatibility.

booleans: A possibly satisfactory solution is to use the atoms true and false? You can call them (one succeeds, one fails), and they are also sometimes used as actual reified truth values (e.g. here: arxiv.org/pdf/1607.01590).
It is very likely that this is not standardised enough, though!

collections other than lists: would be great, but not clear how to do that without making unification introduce constraints: {a|X} = Y would introduce the constraint that X is a set that doesn't contain a. It could work, but would be a big change.

functions: Libraries exist that add this to Prolog. Would be nice to bake some version of that in like DCG is baked in!

--------
strings: I'd love them represented as a "tagged list of chars": string(['h','e','l','l','o']). Syntax sugar would be "hello". The tag would signal the intention, but I would still be free to use my existing knowledge of list manip. predicates and grammar rules (DCG) to transform strings.

If you need to speed up application code, it is rarely necessary to use the non-logical stuff. Instead, you use:
- goal reordering
- redundant spec
- memoization ("tabling")
- constraints (dif/2, clpfd, clpb)
- iterative deepening
- macros
- delayed computation (freeze, when)
- threads
...

It is like unsafe code in Rust: unsafe/nonlogical primitives you can use to implement something safe/logical if you really know what you are doing. So, I don't ever use cut in application programming!

It seems to me that the cut is just one of the several non-logical mechanisms in Prolog. Others are: true mutation (nb_setarg ...), raw term copying (copy_term), ->, *-> ("soft cut"), groundness testing, bagof, ...

Just like you can write memory safe C if you learn what to avoid, you can write logically monotonic Prolog if you learn what to avoid. A better Prolog would be awesome. Sadly, it is not clear (to me) how to remove the surprises you ran into and keep the "wonderfully low level" spirit of Prolog!

Prolog is the assembly language of logic programming. Most of your criticisms are valid. Like Lisp is actually a multiparadigmatic language, the same could almost be said about Prolog. ...

I use codegen for MobX annotations. I've settled for MobX for reactivity, so I can tolerate the slight clumsiness of the code generation. What is a little bit annoying is that code analysis and completion are off if the generated is not up to date.

I have decided to give Dart+Flutter a try a couple of months ago, and decided to switch. The pattern matching is excellent, I can finally manipulate data almost as easily as in Prolog! I also like that D+F forms a cohesive, batteries included whole.

Underrated quasijoke!

And the result will be frustrating, fuelling the received wisdom that structural editing is just a bad idea.
I am a huge fan of JetBrains MPS. But I don't use it that much lately. Guess what -- the reasons have nothing to do with it being a structural editor!

For example, someone might see text as limiting (I do), and invent a visual language. But that language will have some crazy pet semantics, and be visually really fancy, and the tutorial will be idiosyncratic.

I think one very big problem is related to the fact that what convinces people are not ideas but practical systems that embody them. To be practical, the system combines a selection of ideas in a specific way. If the specific system fails to succeed, people dismiss the ideas along with the system.