Complaining about sexprs, when one's baseline is the completely ad-hoc nature of go.mod files, or cargo toml files, is pretty silly. Further, sexprs are a very common general-purpose serialization path for OCaml values, so dune's selection here is hardly arbitrary.
Yes, `dune build`, `dune runtest`, and `dune exec ...` do "work", i.e. each command has its semantics, which are pretty extensively documented IMO. Is the complaint that they're not the same commands that one uses with cargo or whatever?
You're right that opam and dune used to not interoperate much (or at all), but that has changed a lot in the last year or so, to the point that, _if you want_, you don't have to write opam files at all (i.e. they'll be generated from metadata in your `dune-project` file). Again, well documented, at least IMO: https://dune.readthedocs.io/en/stable/opam.html
The "lockfile situation" is pretty good AFAICT. I've been using them for a year+ with good / expected results.
You're right about `dune init` not doing the right things. I believe that's been resolved very recently IIRC, but then again, I can't recall the last language/build tool I used init-like functionality with; I almost always just copy over config/structure from another project I've worked on, and tweak from there.
There are absolutely real critiques of dune, but "it's not cargo" or whatever is silly.