Your claim that declaring a non-integral constant as a static class member “have the detriment of requiring non-integral initialization in the cpp file” is not exactly solid, so to say. It does require a definition in cpp file, but it is not a “detriment”, it is a matter of your intent. Namespace-level const object in C++ has internal linkage by default, meaning that in your original variant the declaration
const string MyStrConst = "String";
is equivalent to
static const string MyStrConst = "String";
i.e. it will define an independent MyStrConst object in every translation unit into which this header file is included. Are you aware of this? Was this your intent or not?
In any case, if you don’t specifically need a separate object in every translation unit, the declaration of MyStrConst constant in your original example is not a good practice. Normally, you’d only put a non-defining declaration in the header file
extern const string MyStrConst;
and provide a definition in the cpp file
const string MyStrConst = "String";
thus making sure that the entire program uses the same constant object. In other words, when it comes to non-integral constants, a normal practice is to define them in cpp file. So, regardless of how you declare it (in the class or out) you will normally always have to deal with the “detriment” of having to define it in cpp file. Of course, as I said above, with namespace constants you can get away with what you have in your first variant, but that would be just an example of “lazy coding”.
Anyway, I don’t think there is a reason to over-complicate the issue: if the constant has an obvious “attachment” to the class, it should be declared as a class member.
P.S. Access specifiers (public, protected, private) don’t control visibility of the name. They only control its accessibility. The name remains visible in any case.