Let's say that I don't feel extremely strongly either way. On the one side, I agree that they are almost surely of limited use in practice, but at the same time, keeping it a disabled-by-default option for one or two versions wouldn't cost us much and seems safer to me. If no-one complains of a performance drop, then cool, we drop them in a few releases. But if some people do experience a performance degradation in some of their workload, then at least we have the option to check if it is indeed due to columns BF. And if it is, we might learn they are more useful than we though.
a rare simplification of our increasingly baroque storage engine code
I hear you. But at the same time columns BF don't add much complexity. Besides, all I'm suggesting is a more incremental/prudent way to remove them.
in the rare case of reading single (CQL) rows from a large partition
I note that it can also help for static rows as this might save you from checking the data file at all in some cases. Not to pretend that this would be very common either.