Because you need to remove them sometimes, and boost-histogram has to work around this by making an intermediate histogram with crop then run projection; having this natively will cut the memory of an operation like h[0:len:sum] in half. Chunks of code in the most complex part of _handle_slice go away.

This was added to boost-histogram's .project as well after a request dating back to 2023. If you make a cut, such as h_new = h_old[10:50, :, :, :], you might want to plot a variable with that cut using h_new.project(2, flow=False). Without the ability to remove flow bins, you can't see the affect of the cut, and you don't want to remove flow bins on the histogram with h_new_plot = h_old[10j:50j:sum, :, :, :] (remember it takes double memory to do so, too!) since you want to keep them for later operations. See scikit-hep/boost-histogram#1032.

You should make the interface correct by default (flow=True), but supporting the full range of options is beneficial, especially for plotting.

Also, having the option tells users, via the interface, that it defaults to full coverage. Not having the option at all makes it ambiguous, it's not part of the interface. (I think h_old[10:50, :].project(x).plot() becomes less confusing if there's a flow=True default in the signature).