A lot of it will come down to design, not just number of switches. For instance, I wouldn’t call a network with 16 stacks of eight switches overly large, but if you have 120 individual switches connecting to each other through various paths and the eventually to a core I’d consider it ‘larger’ - although technically it’s less switches. I’d say measuring the size of a network is more to do with diameter than number of switches (diameter being the maximum number of switches you cross to get from one point in the network to any other point - it comes from spanning-tree design).
What do you mean by ‘slow’ routing? Once the Layer 3 switch has received a packet it’s switched to the new VLAN basically as quickly as a Layer 2 frame is switched; the majority of the work is done in firmware and ASICs, not in software like a traditional/legacy router.
I’d check the event logs for any errors occurring on devices, or anything that is happening on the network that could be causing interruptions to traffic and so stopping the flow of traffic to your Layer 3 switch. It might be a spanning-tree/RSTP event, or a dodgy cable causing port flapping. It might not be your Layer 3 switch at all.
With regards to the MS425, they’re a pretty solid switch so I’d be surprised if you were taking it to its limits. If, after investigation, you do move away from the Meraki core there are other offerings from Cisco beside Nexus now, I’d look at the Catalyst 9500/9600 too. Even with a non-Meraki core you still get great visibility and reporting of clients through the Dashboard.
Yes, technically you could use a PAN firewall in the core instead of the MS425, but in honesty if the MS can’t do the job I doubt the PAN will. I very much believe that you should use the correct device for the job, I.e. use a firewall as a firewall, a switch for switching. Yes there will always be the exceptions where you can’t, normally for budgetary reasons, or occasionally technical reasons, but that should be the exception not the rule.
