Yeah this is good if you, for some reason, rebase then merge without fast forwarding. I never understood doing this. If I'm going to be ignoring those commits when bisecting then they are useless commits just using up disk space IMO.

Does it work well with a classic merge workflow? I haven't worked that way (without rebasing) for a long time.

For me a merge is about grouping commits, when you have just a list of commits, the list can be very long.

That's also useful for bisecting, as you can first find the feature that is buggy and then find the commit that introduced it.

The whole point of bisect is to make it quicker to find a point in a potentially long list of commits. Finding the feature first then bisecting within the branch is only going to make it slower, and requires you to manually restart the bisect.

I use the commit message to add ticket numbers to things to group commits.

The commits surrounding them (logically) are probably also relevant, which you will find easier when you have grouped commits by features.

I prefer to have everything in a single source of truth (git), so everything is in commits. Your tickets are my merge commits.