Well. OH isn’t meant to be a boutique and in fact it isn’t that many interfaces to actually overlap.
On the user UI side, there’s ClassicUI and the more modern BasicUI, just select which one you like better, but essentially now that BasicUI is working reliably, ClassicUI is just still around for compatibility.
There’s also HABpanel, but it’s no all-device Web UI but it is specifically designed to be used on specific devices (tablets), just as are the Android and iOS apps.
On rules, there have always been text files, and there’s openHAB Designer (now called ESH designer), but few people like it and thanks to @kubawolanin the VS code extension has matured as an alternative so now it was declared to be the new standard starting with OH 2.2.
On items, there’s PaperUI and text files and on sitemaps (items, too), there’s the new homebuilder (since 2.2 as well).
On the admin side, there’s habmin and PaperUI. PaperUI is the recommended generic (cross-technology) admin UI while habmin is specific to ZWave (although it also provides quite comprehensive access to items, graphing/persisted data and more). Anyone to run ZWave can use any of these, exclusively or in combination. habmin still provide a little more of the advanced functions.
The main confusion likely is because there’s sort of an overlap of textual (old style you’re used to from OH1) and UI config (PaperUI, default in OH2).
The OH vision is to have PaperUI be applicable for all administration tasks and to do it (or at least offer to do it) visually.
Reality, though, is that it only works for OH2 native bindings and there’s still a number of bindings that aren’t natively available as OH2 versions thus not configurable through PaperUI - MQTT being among these (that one is almost there, though). You do can keep running any OH1 binding, though, with it’s OH1 items syntax config for as long as you like or need to.
On the question why to move, check out this thread, too, please (short summary from that one: start migrating asap so you won’t have to do it in a hurry).
You should follow Rich’s migration tutorial - and specifically for experienced users like you, we hope (or should I say expect?) you to take the opportunity to validate this tutorial and to help enhance it.
Migration also is where autodiscovery fits in … in OH1, there were no things and you had to explicitly configure every item. PaperUI and OH2 bindings offer to auto-create things and items (to the extent possible, depends on how the underlying technology works) to ease first time setup, but you don’t have to take that offer. Specifically when coming from a working OH1 installation, you can rework your items file as the basis for your migration and will not want to create any new items at all. Most users will want to use autodiscovery for things since they’re using a main basic HA system to address most of their devices such as KNX or ZWave, so OH reads and present as things what’s configured in the controller or gateway already, saving a lot of config work.
But quickly browsing your list of bindings, I see none where you could benefit from this kind of config accelerator so yes, feel free to ignore autodiscovery.