No packet that goes from a phone either to your PBX or directly to another phone should ever hit that 50/50 LAN queue. The only thing that 50/50 LAN queue should do is wind up re-ordering your inbound packets as they leave the router headed towards the LAN, it won't even drop anything because it's far faster than the inbound queues on the DSL lines.
Otherwise, phone-to-phone in your organization... all of it should be in the switches. The fact that the 50/50 LAN queue has any effect at all is suspicious and to me indicates maybe a cpu bottleneck on the router or faulty RAM or a driver issue or some other weirdness that the queue winds up accidentally working around.
Before doing anything else, I really think that switch up at the upper right of your diagram that the router, PBX and Centos box are attached to should be swapped out for this device: https://www.amazon.com/Zyxel-24-Gigabit-Managed-Rackmount-GS1900-24E/dp/B00GU1KSHS
And I really think you should have one in operations, sales, and warehouse as well...
make sure you download and upgrade to the latest firmware (there is an especially obnoxious display bug in the older firmwares that make some text invisible in certain browsers in the management interface). Then set up QoS to honor DSCP, and adjust your queues so that DSCP 46 and higher go into queue 7, highest priority
Then your internal VOIP traffic is prioritized and traveling over a high quality switching fabric. Short of faulty wiring, or bursts of RF noise, you shouldn't have a single dropped VOIP packet ever.
Next, since you're going to have a 100/100 metro ethernet connection, upgrade your router to one of these: https://www.amazon.com/Firewall-Appliance-Gigabit-AES-NI-Barebone/dp/B072ZTCNLK
with a single 4gig DIMM and a small flash drive, the whole thing is about $350. Since you already run Centos, run Centos on the router as well (I'd use Debian because that's what I'm familiar with), use FireQOS to shape your traffic. Bond two of the NICs and make that your LAN and plug to the managed switch on a link aggregation group you set up in the switch... so you have some redundancy and get better multi-cpu utilization. Then plug each remaining ethernet separately into each VDSL... later you'll just have one metro ethernet plugged to the router. When that's the case, add the extra ethernet into the bonded group.
Put separate FireQOS queues on each of your DSL lines with numbers tuned to each line. Later upgrade it to just the one metro ethernet queue. Under the metro ethernet queue scenario, put shaping on the output of the WAN and on the output of the LAN, and do no inbound shaping anywhere. Then use firewall rules to ensure all packets are DSCP tagged as they cross the router. Because you're shaping output, the firewall rules run before the queues, and you'll be able to use the DSCP in the queues.
Next, add a squid proxy to the router and have all the internal devices access the web entirely through the proxy. Add some "delay pools" in the squid proxy to limit the speed that people access YouTube or other non-critical bandwidth hogs. This is the best place to slow down YouTube and the like because you can do it based on the URL that's requested rather than based on IP addresses. You can tell squid to DSCP tag its output, so you can lower the priority on this kind of stuff as well.
Once you've got all this in place, cutting over to the metro ethernet should be easy. You can drop the ISDN lines entirely once you have metro ethernet. From a cost perspective my guess is replacing two ISDN lines and two DSL lines with one metro ethernet is probably cheaper, and so spending the money on the hardware to get it working right is a cost savings. Also, no point in working out bugs in your current system when you will get way better performance on the new system, better to upgrade your hardware in prep for that scenario, tune the software, and then cut over.
Can a consumer router running LEDE handle the traffic on metro ethernet? Yes there are devices that can. Can your current router? My guess is just barely. Your performance with a full Centos distribution and 4G RAM and 4 Intel cores to shape traffic and provide a squid proxy and etc... will be enormously better, and extra hardware cost for this setup is marginal, probably less than an afternoon of your salary.