The answer depends on which switch you actually used, and the two that look alike behave very differently.

If it was "Background data" (or Data Saver's per-app restriction), that only blocks the app on metered networks while it is in the background. The moment you open the app it is foreground and the restriction no longer applies — Android exposes this to developers as getRestrictBackgroundStatus(), precisely so an app can tell when it is allowed to transmit again. So anything it banked while restricted goes out the next time you open it. For a data-collecting app that is not a meaningful barrier, because opening it is the normal case.

If your OEM gives a genuine per-app "Allow network access" toggle covering both Wi-Fi and mobile — Samsung and Xiaomi do, stock Pixel does not — that one is enforced on the UID and does block properly, foreground included.

Worth separating the two things in your question, because they are not the same:

• Transmission is what blocking stops. That part works, with the caveat above.
• Collection continues regardless. The app keeps reading whatever it has permission to read and writes it to its own storage. Nothing about network blocking touches that, and it is all still there when access comes back or when you uninstall and the data has already synced through something else.

So "do I need to worry" — yes, but about a narrower thing than it first looks. A blocked app cannot phone home while blocked. It can collect the whole time, and it transmits on the first opportunity. If the goal is that it never has the data at all, the permission screen is the lever, not the network one.

On the VPN-slot problem further up: Android permits exactly one VpnService at a time, which is a hard OS limit rather than something NetGuard chose. The only real ways around it are a firewall that carries your VPN inside it, as suggested with Rethink, or going at it from the DNS side instead.