A place that gets hit particularly hard by losing an alternative delimiter is the API.
rebElide("print {We've relied on this :-( and sucks to lose it}");
If quotes are all we have for strings, mixing inside other language's quotes looks bad fast:
rebElide("print \"We've relied on this :-( and sucks to lose it\"");
One axis for attacking this problem is Sea of Words and Echo, where if what you're doing is not too antagonistic (like the :-( above) you can imagine operators that turn blocks into strings.
In PRINT's case, it might be that @ does exactly this...suppressing the REDUCE:
rebElide("print @[This might just form the contents as-is.]");
Chevrons might actually not be a terrible answer to the issue for people doing a lot of editing in the API:
rebElide("print «We've relied on this :-( and sucks to lose it»");
The idea of sacrificing << and >> themselves to strings is a weird one:
rebElide("print <<We've relied on this :-( and sucks to lose it>>");
It looks too much like tags.
Of course, there's always... backquote... which may just be the best of the bad options: 
rebElide("print `We've relied on this :-( and sucks to lose it`");
In any case, this mixture issue is a real pain point on losing braces for strings. We need to keep apostrophe for what it is, so the options are pretty limited.
Carving <{...}> out of legal tags is another alternative to <<...>> which might come off as a little bit "less taglike"?
rebElide("print <{We've relied on this :-( and sucks to lose it}>");
If you squint, <{ almost looks like its own compound symbol. A relative of ﴾ornate parentheses﴿ or perhaps ⦓Arc Brackets⦔
Does It Seem Worth The Sacrifice?
For all that freeing up FENCE! does, can we suffer through <{...}> strings and/or backticks?
It feels like a tradeoff worth pursuing.
I think a nice thing about <{ is that it isn't something that would be sought after as an operator in its own right, the way << would.