(please excuse my poor english, I'm not a good speaker, hope that something don't get lost in translation)
Honestly, when I read the docs, I were very puzzled by the change from 4096 to 1048576. The first thing I thought was "how much memory this will consume?", but if Debian uses this, maybe it's not that bad.
Returning to your question: no, I haven't tested this option on different machines and workloads, because a paid developer from Valve software maybe already did it for me. Testing is already happening now on thousand of PC running Steam Play (if you check the Steam hardware stats, Ubuntu is the main distro used with Steam).
On my PC that setting didn't make any difference in performance or responsiveness.
Like it or not, that setting (or a more limited version of it, which I'd honestly prefer) is needed to let Steam Play works out of the box with the vast majority of games: I discovered some games that don't work otherwise. There's always the possibility to switch off completely the esync thing, but this requires manual intervention by the user.
The choice is: let make it work once and for all without human intervention or let the Manjaro users do the usual gimmicks.
About the fork bomb: my request is limited to Steam Play, that means that I suppose you use your PC to play games. You are not running a server, nor important services available 24h a day. With my suggestion, if you don't have Steam, you don't have problems. Yes, there could be some badly written software that will fork bomb, but I highly doubt it isn't already malicious per se.
If this is a so big problem, we can create a package called
this-makes-steam-play-work.tar.xz and tell people to install it as a temporary solution and with a big warning about the consequences.