Explicit direct #include vs. Non-contractual transitive #include

You should use explicit #includes to have a non destructive workflow. Let's say that MyClass is used in 50 different source files. They don't include vector. Suddenly, you have to change std::vector in MyClass.h for some other container. Then all the 50 source files will either need to include vector or you will need to leave it in MyClass.h. This would be redundant and it could increase application size, compilation time and even run time (static variable initialization) unnecessarily.

to prevent a dependency on the internal workings of MyClass. Or should I?

Yes, you should and for pretty much for that reason. Unless you want to specify that MyClass.hpp is guaranteed to include <vector>, you cannot rely on one including the other. And there is no good reason to be forced to provide such guarantee. If there is no such guarantee, then you rely on an implementation detail of MyClass.hpp that may change in future, which will break your code.

I obviously realise that MyClass needs vector to work.

Does it? Couldn't it use for example boost::container::small_vector instead?

In this example MyClass needs std::vector

But what about the needs of MyClass in future? Programs evolve, and what a class needs today is not always the same that the class needs tomorrow.

But would it not be good to be able to decide which headers get exposed when importing

Preventing transitive inclusion is not possible.

Modules introduced in C++20 are a feature that may be used instead of pp-inclusion and are intended to help solve this.

Right now, you can avoid including any implementation detail dependencies by using the PIMPL pattern ("Pointer to implementation"). But PIMPL introduces a layer of indirection and more significantly, requires dynamic allocation which has performance implications. Depending on context, these implications may be negligible or significant.