These days with C++11's auto, this is improved a lot. It's not full type inference, but eliminates most of the boilerplate, and arguably what's left you really want to keep for documentation purposes.
> The object-oriented representation of a trivial sum type as an inheritance hierarchy of classes is needlessly inefficient.
This use case strikes me as a particularly bad example of sum types: The author wants to represent different kinds of scene members, like spheres and groups, as a sum type. Using a sum type means that anyone wanting to add a new kind of object has to add it to the sum type and handle it everywhere, which will quickly become problematic. Using object-oriented design allows new object types to be introduced without updating everything.
Basically the sum type looks nicer here only because it's a toy example and we're not considering how it will evolve.
That said, I do think sum types are really useful in some use cases, especially in compilers, and I'm sad C++ doesn't have them. I tend to end up defining ASTs using Cap'n Proto as a convenient way to declare a tagged union, even though I have no intent to serialize the structures.
> No need to write constructors for tuples, records and variant types in OCaml.
To be fair, for an all-public struct (as in the example), you don't need constructors in C++ either.
Once you have private members, then of course you need a constructor.
> Native lists in OCaml.
C++11 initializer lists make it basically possible to write list/vector/array classes that "feel native".
> Higher-order functions instead of loops in OCaml.
C++11 lambdas, etc. However, in a lot of cases, loops are easier to read.