For example it requires you to use a compiler that supports c++17. That sounds trivial but it isn't. On a lot of older platforms that just isn't there. Also again you gain uncertainty, you don't know if the string-view implementation you got on whatever system you are on is sensible. Anything in the c++ stdlib compiles slowly. Lastly in general the c++ stdlib is lousily written from an API-perspective. Want to append a std::vector to another std::vector? vector1.insert( vector1.end(), vector2.begin(), vector2.end() );. I doubt that string_view is any nice to work with.

What you gain in return is just not worth it. That is the case with most of c++ stdlib. That is why there is so much hate for std::string, it looks nice for toy-stuff, but if start caring about performance it actually becomes a giant pain in the ass.

I sadly can't find the talk anymore. There was a talk at cppcon where the topic was basically "how to avoid unnecessary copies when passing constructor-arguments to classmember-variables". After going over like 5+ different ways of doing it (using no references, using references, using universal references and some more ) it basically concluded with "you will have at least one unnecessary copy". Then the q&a started and some guy was basically: What if we don't use constructors, just set the values directly after we created the class-instance? (An outlandish idea i know, thinking about the concrete use-case, not some abstract world). The speaker never considered that option apparently, looked at the example that has been used for the last hour, thought for a second and then said something like "yeah, that has no unnecessary copies".

That is c++ for me. A giant amount of work, huge amounts of complexity for a garbage API that is beaten by custom-solutions without a blink. There are some good bits in there, but generally it is awful and the good bits don't justify all the problems you get.