• I agree with your assessment here; isinstance(value, _CONVERTIBLE_TO_STR) (where _CONVERTIBLE_TO_STR = (str, int, float)) is simpler and better than _is_convertible_to_str(value). It is also a little bit faster, which I determined by measuring execution times with timeit.
• _contains_any looks like it was written in a way so it can be useful in a general sense, e.g. it could be part of a utility library. But right now the only way it is used is to check if a string contains any whitespace. For simplicity and performance, I would go with something like this instead:

  def contains_whitespace(text: str) -> bool:
      return any(character in _WHITESPACE for character in text)
  

  Based on measurements with timeit and randomly-generated strings, I found that this was also generally faster than _contains_any(text, _WHITESPACE).
• You can get a small performance boost by using string interpolation with f-strings (f"{quote_str}{string1}{quote_str}") instead of string concatenation via the + operator (quote_str + string1 + quote_str), and the good thing is the f-string version is just as understandable and clear.
• For flist_to_str, I would make some naming changes.
  • If I pretended that I didn't know the context of the larger problem, seeing the names flist_to_str and flist: list[str] and the documentation "flat list of strings", I would probably wonder, "Why a flat list of strings? How is that any different from a list of strings?" And if we look at the type hints there really isn't a difference, so I would change the following:
    • flist_to_str -> list_to_str
    • flist: list[str] -> items: list[str]
    • "flat list of strings" -> "list of strings" (in the documentation)
  • quote_str: str -> quote_mark: str
    • I think this is a little more precise.
  • string1: str -> text: str
    • I totally understand choosing string1 to avoid shadowing the string module and the built-in str function, but text is probably a better choice here.

In summary, there were some small nits pointed out here and there but overall I found the code and the public API it exposes very well-documented and easy to read. The docstrings were useful and had illuminating examples; I didn't think they were excessive at all.

• I agree with your assessment here; isinstance(value, _CONVERTIBLE_TO_STR) (where _CONVERTIBLE_TO_STR = (str, int, float)) is simpler and better than _is_convertible_to_str(value). It is also a little bit faster. I determined this by measuring execution times with timeit.
• _contains_any looks like it was written in a way so it can be useful in a general sense, e.g. it could be part of a utility library. But right now the only way it is used is to check if a string contains any whitespace. For simplicity, I would go with something like this instead:

  def contains_whitespace(text: str) -> bool:
      return any(character in _WHITESPACE for character in text)
  

  Based on measurements with timeit and randomly-generated strings, I found that this was also generally faster than _contains_any(text, _WHITESPACE).
• You can get a small performance boost by using string interpolation with f-strings (f"{quote_str}{string1}{quote_str}") instead of string concatenation via the + operator (quote_str + string1 + quote_str). Nothing huge, but improving performance without having to sacrifice readability is pretty nice.
• For flist_to_str, I would make some naming changes.
  • If I pretended that I didn't know the context of the larger problem statement, seeing the names flist_to_str and flist: list[str] and the documentation "flat list of strings", I would probably wonder, "Why call it a flat list of strings? How is that any different from a list of strings?" And if we look at the type hints there really isn't a difference, so I would change the naming to make that more clear:
    • flist_to_str -> list_to_str
    • flist: list[str] -> items: list[str]
    • "flat list of strings" -> "list of strings" (in the documentation)
  • quote_str: str -> quote_mark: str
    • I think this is a little more precise.
  • string1: str -> text: str
    • I totally understand choosing the name string1 to avoid shadowing the string module, but text is probably a better name here.
    • To be fair, coming up with a good generic name for a string in Python is hard because the two best candidates (str and string) are already taken by a built-in function and a standard library module, respectively. I always end up using something like s or text as a result.

In summary, there were some small nits pointed out here and there but overall I found the code and the public API it exposes very well-documented and easy to read. The docstrings were useful and had illuminating examples; I didn't think they were excessive at all.