While I agree on the situation at hand (being able to use did you mean
or disable it at the discretion of the user), I think there was a wrong
filing in the linked issue in that the suggestion of the linked in
thread was "Revert did_you_mean promotion to default gem", and that
is different to the situation of "make did-you-mean gem
optional/disablable", if the latter is a word.
In other words, I think the filing should be on the topic at hand, and
there is a big difference between:
a) making did-you-mean optional
versus
b) revert promoting did-you-mean gem to default
I am all in favour of a), but not in favour of b).
If I understood your use case or situation, then I think that a) would
be the proper solution which should fit nicely with the "general" philosophy
in ruby to let the ruby user decide what to use, when to use it and so
forth. E. g. to let people customize how they use ruby for their particular
use case.
Reverting the addition of did-you-mean is different to making things
customizable. It's a similar reasoning I mentioned before in the integration
of bundler - I myself do not use bundler (only rubygems), but other ruby users
do, and the rubygems team pointed out in the past that there is unnecessary
code duplication; so the long-time best solution was to integrate both
approaches, which may help the ruby ecosystem in the long run, even though
it can short-term issues (I think you mentioned fedora/red hat packaging
before, but debian also wanted more flexibility too; see also other
aspects related to changes, such as wanting to have the possibility for
reproducible builds).
Anyway, to finish this lengthy comment, I think it is much better to make
the software at hand as flexible as possible, to allow for different use
cases - but not at the expense of other users. That has always been part
of ruby really (e. g. see the ability to modify ruby via duck patching
at all times). And again, I agree that it should be flexible, but that is
not the same as an reversion; it's different.
Updated by 
Updated by 
Updated by 
Updated by