Could we get reasoning for why some rules that are enabled in RuboCop by default are disabled?

[TastyPi]

I've been playing around with what our codebase would look like if we used RuboCop's default configs instead of Standard. For the most part I prefer Standard's choices over the defaults. But sometimes I come across a rule that I don't understand why it was disabled, and can find no reasoning for it. Usually these are cops provided by rubocop-performance, for example Performance/MapCompact. It's obviously subjective which of map {...}.compact or filter_map {...} is more readable, but when one is more performant than another it seems like that option should be chosen? Unless there is another reason to prefer map {...}.compact?

I find RuboCop to be a fantastic tool to learn about Ruby features that can improve my code, so it seems a shame to disable rules that could be improving the code of people who are unaware of the alternative. Obviously we can enable these rules ourselves, but that kind of goes against the spirit of Standard.

This is just an example, in general it would be nice to have more of an insight into why a rule has been enabled/disabled, even if it's just a short comment in the config file.

[camilopayan]

Often when there's an unsafe autocorrect, like with MapCompact, we leave it out because ideally a team can run Standard and get a codebase that functions exactly the same.

For the rules in rubocop-performance that's been especially the case! Good question though, and I'm sure we'll figure out more ways to spread the reasoning behind why certain rules are enabled/disabled. One thing I've started trying to do is actually make those decisions on YouTube livestreams because that's a fun format for this, but obviously it's unlikely someone would want to watch an hour video to find out "oh it's because the autocorrect has false positives."