A more flexible solution using x64dbg
In addition to ollydbg2's built-in experimental support, it's relatively easy to achieve something similar in x64dbg, although some manual scripting is required. Using x64dbg's SetExceptionBPX function, you can define any exception to be treated as a breakpoint by x64dbg instead of being treated by regular exception handling logic. You will then need to create your own "breakpoint" handling logic (create & delete breakpoint) by modifying code at desired addresses to trigger that exception and restore it afterwards.
Answering the broader question
Additionally, you've asked
why debuggers don't support generating different exceptions for software breakpoints? For programs that have anti-debugging mechanisms like scanning for unknown
so I'll go ahead and answer the broader question.
Although you accurately noted debuggers default to use the
int3 instruction for breakpoints, that is definitely not the only one. Several debuggers (especially those geared towards malware analysis and combating anti-debugging) have started implementing additional software breakpoint methods precisely for that reason. debuggers such as ollydbg and x64dbg implement multiple breakpoint types both for different debugging functionality (i.e. memory/data breakpoints) and for stealth (such as less common tricks to trigger an interrupt that the debugger may catch).
For most of the more common debugging tasks, these are just unnecessary for the majority of debugger use cases, therefore many debuggers are never required to use any alternative exception triggering instructions. The user base for say, gdb, is mostly software developers that never encounter the need for such features.
Why division by zero is a suboptimal choice regardless
Lastly, you've asked specifically about a division by zero exception being used as a software breakpoint alternative, so I'll include a few drawbacks for using division by zero specifically.
Is it possible to generate a software breakpoint other than int3 to be catched by the debugger, like a division by zero for example?
That one, specifically, is more known but is a suboptimal choice compared to alternatives. It's avoided even by debuggers providing many software breakpoint alternatives because it is a more difficult exception to generate and cleanup compared to single byte instructions such as
div instruction requires either a register or a memory address and cannot accept an immediate value for the divisor, you're required to prepare a register or memory address with the value zero, as well as generate a longer instruction which may be a little riskier if overwriting multiple instructions of the original code. For those reasons, division by zero is far less convinenet to use as a software breakpoint alternative.