Using bare /.../ as delimiters allows for far too much ambiguity for my comfort. The syntax for prefix/postfix/infix operators in Swift already has a bunch of awkward edge cases around spacing, and the proposed syntax compounds it. Consider one example from the pitch text:
let x = arr.reduce(1, /) / 5
It was mentioned that this would be fine because a regex literal that starts with a ) wouldn't be valid so it wouldn't be parsed as one. That's fine, but if we change the function signature slightly, we end up with it being lexed entirely differently:
let x = arr.reduceButAlsoSomethingElse(1, /, foo) / 5
And now we have another edge case that requires the user to wrap the operator function reference in (...), but only sometimes. We already have some of those in the language (e.g., let x: (Int, Int) -> Int = + is impossible, you have to write ... = (+)), and we ought to avoid adding more unless we're going to just say "source compatibility break: all unbound operator references must be wrapped in parens". But I don't think that kind of source compatibility break would pass muster, so why should the others described here?
If Swift's syntax was being designed from the ground up, maybe it could be possible to fit /.../ into the syntax while not sacrificing other features. But we have an already-existing language with years of evolution, and IMO the parsing challenges and special cases described by the pitch are proof that bare /.../ is not the right solution for Swift today. There is no real harm in not using /.../ other than that they don't look exactly like regular expressions in other languages, but there is active harm in arbitrarily prohibiting entire classes of custom operators in a language that claims to support those.
The un-pitched-but-mentioned-by-others-in-this-thread alternative of "just use #/.../# everywhere" sounds ideal to me. It's unambiguous, barely more intrusive, and doesn't cause harm to other parts of the language grammar or its usability.