So where most Linux distributions would keep shared libraries in a common directory like /usr/lib, NixOS doesn’t even have a /usr/lib and doesn’t symlink its libraries from a shared location. Instead, each package links to the specific versions of the specific shared libraries it needs in the Nix store, avoiding any path collisions. So in addition to the symlinks, a precompiled binary needs to be patched because the linker stage of compilation has inserted references to shared libraries in /usr/lib and these need to be changed to point to correct Nix store locations.
The specific problem when it comes to VCV Rack Pro is that normally, the Nix package manager would just pull the binary from some public URL, unauthenticated, run a checksum, and do that patching in the background so the user doesn’t have to worry about it. (You’re right to compare it to Gentoo; I think it also shares some traits with BSD ports and container image manifests.) But my understanding is that it can’t do that with VCV Rack Pro because downloading that binary requires being logged in (authenticated) to the VCV Rack web site using an account with a verified purchase. So installing Rack Pro on Nix would require some alternative approach like giving Nix access to the user’s VCV Rack account credentials or providing some mechanism outside the standard package database for patching and installing the binary after the user has manually downloaded it. Actually a relatively easy way to do it would be to run the binary in a container based on a more standard Linux distro, but part of the charm of Nix is that it offers some of the sandboxing and dependency management properties of containers without the CPU overhead.
Anyhow you’re probably right that this is better handled by contacting support directly, but since I only use standalone Rack (though I’m a VCV commercial plugin customer) I want to prove that people would actually use Pro on NixOS before I make the case to VCV Rack devs that they should support this.