Does it make sense to rename this to something like drop_geometry_data? In particular, as the new parameter name suggests that that also plain DataFrames (not only GeoDataFrames) are okay.

At first my idea was to only write df = gdf.drop(columns=gdf.geometry.name). But I thought it would be saver to check if the given DataFrame is actually a GeoDataFrame. In fact, the previous version of that function actually works with DataFrames, because it would not change anything if no column named "geometry" is found.
Therefore plain DataFrames were ok before, and are ok now. I feel like renaming the input to "df" is only logical, in that sense.
I do not feel the need to rename the function, but I would not argue against it.

Can you please add a comment when this might happen?

If I remember correctly, I had a case where weld_segments would just delete all lines in a network. Adding that change did not solve my actual problem (because it only returns the previous state of an almost deleted network) but it simplified searching for the root of the problem by not breaking the following code (which would throw other errors with an empty network).
I must admit that I did not store the problematic input network and cannot remember the details. As I said, it was a rare edge case.

Why this?

There are other places in the code (e.g. specifically geometry_operations.split_multilinestr_to_linestr() called at the beginning of connect_points.process_geometry()) which make sure there are no MultiLineStrings in the network. I cannot tell where exactly, but this causes issues somewhere down the road.
Once again I sadly do not have a reproducible example of this, but this single line once fixed a problematic network I worked with.