From your post the majoritiy of your CPU usage is routing and bridging.
The block diagram of the CCR2004-1G-12S+2XS is here, and you can see it has no integrated switch chip.
You must be doing something that is preventing the CRS from offloading the switching to the switch chip, because the CRS block diagram has a 12 port non-blocking wire-speed switch build in to handle the L2 switching functions in dedicated hardware.
So something in the config is causing the switching function to be done by the software bridge, and the CPU in the CRS312 is meant for management functions only. And it won't be able to route or bridge in software with the performance you need. Compare the switching vs ethernet (CPU software based) performance numbers.
The one thing I notice in your config is that you have a vlan interface defined for VLAN 1, but the bridge itself is using vlan 1 too. And you have two different interfaces (both using the same ip address 192.168.100.1) accessing the same vlan on the switch.
Unless you override it, the bridge interface itself will have pvid=1. Since you don't override the pvid, any traffic from the bridge interface itself (vlanBridge) will use vlan 1 on the switch.
/interface bridge
add igmp-snooping=yes multicast-querier=yes multicast-router=permanent name=\
vlanBridge port-cost-mode=short priority=0 querier-interval=30s \
query-interval=30s startup-query-interval=15s vlan-filtering=yes
But you also explicitly create a vlan interface for vlan 1
/interface vlan
add interface=vlanBridge name=vlan1_Management vlan-id=1
add interface=vlanBridge name=vlan10_Shelly vlan-id=10
add interface=vlanBridge name=vlan20_Guest vlan-id=20
add interface=vlanBridge name=vlan30_Office vlan-id=30
add interface=vlanBridge name=vlan40_Dante vlan-id=40
add interface=vlanBridge name=vlan50_Cams vlan-id=50
A vlan interface inserts/removes tags and uses the parent interface for transporting the tagged frames; in your case the parent interface is the bridge (vlanBridge).
If you issue the CLI commands:
/interface/bridge print
/interface/bridge/port print
/interface/bridge/vlan print
You will see what is being used.
Also a verbose export of bridge will show it has pvid=1.
I see you have added an address to the bridge itself here: And I am surprized it even allowed you to do this, you are using the same ip address 192.168.110.1 for vlanBridge (the bridge itself) and also for the vlan 1 (sub) interface.
/ip address
add address=192.168.104.254/24 interface=ether1-UL-Fritzbox network=\
192.168.104.0
add address=192.168.111.1/24 interface=vlan10_Shelly network=192.168.111.0
add address=192.168.112.1/24 interface=vlan20_Guest network=192.168.112.0
add address=192.168.113.1/24 interface=vlan30_Office network=192.168.113.0
add address=192.168.110.1/24 interface=vlan1_Management network=192.168.110.0
add address=192.168.114.1/24 interface=vlan40_Dante network=192.168.114.0
add address=192.168.115.1/24 interface=vlan50_Cams network=192.168.115.0
add address=192.168.110.1 comment="for IGMP-Querrier" interface=vlanBridge \
network=192.168.110.1
That looks like a misconfiguration to me.
While on the topic of vlans and ip addresses, a vlan that isn't reserved (and is supported by your hardward) can be used as a container for any ip subnet, but for ease of maintenance and understanding, a common convention is to use a vlan id that has something in common with the subnet's ip address. The most common convention for ip subnets with /24 masks is to use the decimal value of the third octet as the vlan id; e.g. for your camera network with ip address 192.168.115.0/24 it would be more common to see vlan 115 used than vlan 50. But 50 will work as is without causing any problems (other than possible confusion for someone expecting the standard convention). But the way you have it is much better than using vlan 115 for ip subnet 192.168.110.0/24 and then using vlan 100 for subnet 192.168.114.0/24, that would be even more confusing.
If you want to understand what the bridge device does (three different things), I recommend reading RouterOS bridge mysteries explained by sindy.
The bridge interface (part of the Iinux kernel) itself always sends untagged traffic. And the router facing bridge port of the "vitual switch" by default has a pvid of 1 (as do all other bridge ports by default). The virtual link between the router and the virtual switch is a "hybrid" trunk, with untagged traffic going between the linux bridge interface and vlan 1 in the switch. You can change what vlan untagged traffic is mapped to by specifying a pvid on the bridge interface. If you want vlan 1 tagged (I wouldn't), then to reduce confusion, you should set the bridge pvid to something else (it can be an unused vlan), and don't apply any ip address to the bridge itself. But your choice of vlans ( at least for 10,20,30,40,50) has nothing to do with any problem you are seeing. However, your vlan 1 misconfiguration, having two interface both using vlan 1, one tagged (vlan1_Management) and one untagged (vlanBridge), and having those two interfaces both use ip address 192.168.100.1; that is probably contributing to the problems you are seeing.
As to your question about what to do with the CRS312, I would still use it. It will handle intra-vlan traffic between your other switches without that traffic ever even reaching the CCR. The CCR will have to do all inter-vlan (between vlan) routing.
How much traffic to you really have? Is most traffic intra-vlan (within the same vlan), or do you have a lot of inter-vlan traffic (between vlans)? What is the purpose of the vlans? Is it because you want to use a firewall to keep things separate?
If most of your traffic is within the same lan (and it probably is), then having the switch will be an advantage, especially if that vlan is used across all your switches.
If there is one "main" vlan that will communicate with the other vlans, you may get marginally better performance it you dedicate a CCR port for that vlan and have a second connection between the CRS and the CCR (I would just use untagged, and configure the port on the CRS as an access port for the particular main vlan). But that's a optimization, get things working with a single trunk port between the CRS and the CCR to start with. Because without knowing what is being routed between vlans, you won't be able to know which vlan to give preferential treatment to.
P.S. you have a typo in your first post (change CCR-2002... to CCR-2004)