Cisco background and bridging isn't a feature on switches (well there are a couple commands that relate to bridging but never used on access level switches)
I don't know IOS at any serious level, but a bit of web searching turned up
this feature of IOS, which looks like what RouterOS calls software bridging. Hardware-offloaded bridging is simply doing this on the switch chip, rather than send everything down through the CPU.
The last time I heard of bridges it was in the context of an individual device that quite literally "bridged" two separate networks together (or separated CDs)
Yes, that's one use. Although such 2-interface hardware devices were more common when there were more incompatible LAN technologies in use (e.g. Ethernet to TokenRing bridge) they're still found as in WiFi to Ethernet bridges, or PowerLine to Ethernet bridges.
Then you have the software abstraction of that concept, as seen in VM hypervisors.
That is then further abstracted in the Linux kernel, from which RouterOS's use of the term comes.
These uses aren't incompatible. You can use a Linux kernel bridge to implement 2-port media translation bridges, VM hypervisor virtual-to-real network bridges, and virtual Ethernet switches.
the ports need to be bridged first.
If you want multiple ports in a single broadcast domain, yes.
However, one common situation on RouterOS is to have a single WAN uplink port that isn't in any bridge at all, because Ⓐ there is no need for a broadcast domain; and Ⓑ the underlying switch port supports only one hardware bridge, so you may get no benefit of putting the single WAN uplink port into a bridge; or Ⓒ it's a proper router, so all bridges are in software, so case B goes double.
That said, I warned above that some things can only be done in a bridge. Just last week, someone here wanted to do bridge VLAN filtering on the WAN side, which required a single-port bridge just to gain access to the RouterOS VLAN filtering features needed on that WAN uplink port. There is no "switch VLAN filtering" feature in RouterOS for what the other poster wanted: their desired feature is handled at the bridge level because it works for both hardware and software bridges.
after configuring three different bridges (one for WAN, LAN and DMZ) all of my ports still show HW as enabled
As expected, from the docs' claim that you can have up to 7 hardware bridges on your switch model.
Contrast something like an RB5009, which supports only one hardware bridge. That's fine, since it's often used in cases like above: single WAN uplink port, and everything else bridged together for the LAN. Even if you end up needing a software bridge on the WAN port, the collective throughput of that one port is low enough that a software bridge is likely to work at line rate, whereas the many other ports could in aggregate spam the CPU if it wasn't for bridge hardware offloading.
you never want to leave a port untagged (and change the Native VLAN from default VLAN 1) as this reduces the chances for VLAN hopping, which I don't think is a vulnerability that is commonly exploited but it's always stuck with me.
RouterOS also uses VLAN 1 as a kind of generic fall-back, so yes, if you're using VLANs for security isolation, none of the ports should use PVID 1.
Contrast VLANs used as lightweight routing, where the PVID 1 consideration doesn't come into it. You see this with ports intended to allow both untagged and tagged traffic so that traffic that knows where it needs to go can be pre-tagged and traffic that does not gets a sensible default VLAN tag. Here you're depending on the default PVID and good behavior among those that don't use that default to get a useful feature.
Example: You've got a public access port that puts untagged traffic onto the customer VLAN, but if someone plugs in an IP cam preconfigured with an 802.1q tag for the video VLAN, it goes over to the DVR instead. Port isolation doesn't enter into this sort of configuration: merely by one device's say-so, it got traffic onto the video VLAN instead of the customer VLAN.
Is this wrong? It depends on the security design and local IT policies. If it's a security cam and the DVR is intended as a tamper-proof record for law enforcement, it's probably not a smart idea. If instead the IP cam is for capturing events happening in that room, archived on the DVR, this design is likely not only harmless, but helpful, since it saves the need to pull a dedicated Ethernet drop to the room, merely so you can hard-tag it to the video VLAN.
One thing VLANs give you that physical LANs chained together do not is that a single port can be in multiple VLANs at once. That's not your use case: each group of bridged ports is non-overlapping. This is why I say that, as you've documented it so far, I don't see a need for VLANs in your configuration at all. The separate hardware bridges do the isolation for you, and traffic moves between them under control of routing rules.
If your use case is wider than that, then in those areas where VLAN isolation is all that's keeping your traffic on those shared ports from intermingling, you might have cause to think about PVID defaults and such.
I actually have about 7 VLANs lol.
My point is, with that CRS, you could just as well have 7 bridges instead. It's the same subnet scheme and the same firewall rules between subnets to control which bridge can talk to which other, but it's done at the port level, with each port in a single distinct subnet.
Until you find yourself needing to say that a given port is in 2+ subnets for some reason, VLANs aren't buying you anything extra over the same number of bridges.
I'll give you a counterexample: in your reply, you mentioned the possibility of adding a proper router to the CRS. (This is a good idea, by the way, since CRS1xx/2xx aren't great as WAN routers due to lack of CPU power.) If the CRS moves into a core network function, you might then have a trunk link from the CRS to the router, and you'd then want to use VLAN tags in firewall rules to say things like "the Plex VLAN can only talk to the entertainment system VLAN and to the Plex cloud," and "the guest VLAN can talk to anything on the Internet, but nothing on the LAN."
That would be a good justification for VLANs over bridges.