I think it is important to consider ‘separation of concerns’ such that Strings work with Strings and Chars work with Chars. It would likely be a violation of this rule to have Strings accepting chars as direct input elements - which is why the current mechanism requires the use of both.
We also need to remember that good programing practices allow us to combine basic building bocks into more complex functionality using ‘loose coupling’. If we provide a method in a string class to manipulate chars then we are creating a dependency between the two concepts (string and char) which is a form of tight coupling - this leads in the long-run to architecture hardening which can be difficult to undo.
Extension methods can be useful to solve repetitive complex problems, however, when they are used for just providing a wrapper around simple existing functionality (in this case, saving the programmer the effort of converting a char to a string), then we need to look at readability and maintainability of the resulting application. What wrapper functions do is hide the intent of a piece of code from the reader who may not be the person that originally wrote the code. This increases what we call cognitive complexity of the code which can lead to a higher risk of introducing defects (by inference). Cognitive complexity is one of those things that are sometimes a necessity but a thing we need to keep to a minimum.
Finally, when referring to performance I think it is important to look beyond the high level language (C#, VB) and understand what the compiler is doing at the ILSM level and also what the CPU is doing at the assembler op-code level. Both are exceptionally capable of understanding the string/char pattern intents signified by the code and optimising the implementations for maximum performance.