While I like using data() instead of c_str(), note that string view is supported here:

// clang-format off
  #ifdef FLATBUFFERS_HAS_STRING_VIEW
  /// @brief Store a string in the buffer, which can contain any binary data.
  /// @param[in] str A const string_view to copy in to the buffer.
  /// @return Returns the offset in the buffer where the string starts.
  template<template <typename> class OffsetT = Offset>
  OffsetT<String>CreateString(flatbuffers::string_view str) {
    return CreateString<OffsetT>(str.data(), str.size());
  }
  #endif // FLATBUFFERS_HAS_STRING_VIEW
  // clang-format on

Here, the parameter is passed by value (string view style), not const reference (string style) as the code.
I guess keeping both is fine. Alternatively, there could be a second templated function OffsetT<String> CreateString(T str) instead instead of the flatbuffers::string_view one.

note that string view is supported here

But what if we have struct derived from std::string_view? OffsetT<String> CreateString(const T &str) is more prioritized in this case.

Alternatively, there could be a second templated function OffsetT<String> CreateString(T str)

Wouldn't this lead to ambig with OffsetT<String> CreateString(const T& str)?

.data() should be fine, since .c_str() and that are the same post c++11, which is the oldest standard we support.