That being said, this is about GUI. No reason not to do as much native processing as your heart desires outside of your GUI layer.
You're not running 20 different tracks with compression, reverb, chorus, delay + send/return tracks + sub mixes in your app. Your app has absolutely nothing to do with a DAW. You're not taking MIDI input or running virtual instruments either. Try to do that in a browser with a latency < 10ms like Cubase or Logic and see how it goes.
Again, your product has absolutely nothing to do with a DAW and its constraints, so don't try to claim it's an achievement of some sort.
This is like trying to build Maya or Blender in a browser without an art background but having to deal with ms latency.
I just don't see the point. I don't even like Logic because the Cubase workflow is transparent to me at this point.
Even the idea of grabbing pirated DAW software to get an intuition is kind of absurd if you have never made music at all. It is exactly the problem I have had with trying to learn Maya. I can't even draw something on paper. The idea a dev with no background in the domain is going to add something to software that has been evolving from very specific domain knowledge in a highly complex and unbound domain for multiple decades is utterly absurd.
I suspect that existing web-as-native-GUI frameworks make presumptions about threading that won't work where a realtime audio callback thread piping data to other audio processing threads and back is the real show, and where the GUI may need things like updated zoom levels dirtying many waveform drawings at once requiring recalculation of peak values in viewable windows to draw the little lines that make the waveform, among other things that may make simple partitioning of systems more challenging...
DAW can use pretty much all of system resources (RAM, CPU, disk IO) during playback. If any other thread steals CPU for for too long during playback, like GC of an UI thread, this can introduce audio clicks/pops.
Video conferencing app has tons of network latency which helps to hide other latencies. That kind of latency would be unacceptable in a DAW. Video conferencing app also doesn't starve system of resources like DAW can, so it's UI can be more resource-intensive.
Latency in a DAW isn't just at a premium, it's configurable and needs to be reported and compensated for. That means if any audio processing adds latency, all other processing units must compensate with their own internal (or external) delays to avoid the signal going out of phase.
Apart from that, I don't see how any of this is relevant to how you build the GUI for a DAW.
How much? As GP said, > 5ms is instant disqualification. And that is for your whole app, not just the effects pipeline.
GP is right, go use a DAW in a serious setting for a while to build up an intuition of the needs of these users.