The point of types is to prove the absence of errors. Dynamic typing just has these errors well-structured and early, but they're still errors.
Maybe for you. Originally static typing was to make the job of the compiler easier. Dynamic typing was seen as a feature that allows for faster prototyping.
And no, dynamic typing does not mean untyped. It just means type errors are checked at runtime instead of compile time.
You can have strongly typed dynamic languages. Common Lisp is a very good example.
Weak typing is a design mistake. Dynamic typing has its place as it allows you to have types that are impossible to express in most static type systems while avoiding the bureaucratic overhead of having to prematurely declare your types.
The best languages allow for gradual typing. Prototype first then add types once the general shape of your program becomes clear.
> It just means type errors are checked at runtime instead of compile time.
This is a fundamental misconception. A type checker proves the absence of errors. It doesn't check for error conditions. That is: A program that isn't (cannot be proven to be) well-typed can very well be correct. But a program that is well-typed is guaranteed to be free from certain errors.
What you call "dynamically typed", in contrast, is comsequent just value inspection and stopping the evaluation/execution early. A program that has been executed successfully often is not necessarily correct.
If you want to apply the same operation on all of them, then they share some API commonality -- therefore you can use polymorphism or type erasure.
If they don't, you still need to know what types they are -- therefore you can use `std::variant`.
If they really are unrelated, why are you storing them together in the same container? Even then, it's trivial in C++: `std::vector<std::any>`.
