You're arguing about requirements. Of course when Thompson and Ritchie went for null terminated strings, they knew that NUL would be excluded. That's the specification at the requirement level; it's not a "oh crap, we unwittingly excluded NUL from strings" bug.
There are 32 control characters, and DEL. The purpose of all those characters is to carry some kind of meaning. The designers of the null-terminated string decided that the meaning of NUL will be reserved for that termination. That still leaves 31 control characters and DEL which can be stored in a string, which programmers can use for other meanings. That turns out to be plenty.
The "unreasonable effectiveness" and ubiquity of null terminated strings shows that the world is perfectly capable of getting along without NUL in the middle of a string. Basically, the intuition that we can steal NUL for string termination was right (and to some extent self-fulfilling, due to the subsequent proliferation of the convention).
The idea that all possible code points of a character set are valid characters that must be stored in a string is outdated in the age of Unicode, which contains codes which are not character code points.
Null terminated strings are now the representation of a path name every major OS that has any non-negligible installed base. The choices leading to this situation weren't made by complete idiots.
And, by the way, NUL is the ASCII character; NULL is the pointer constant in C.