Your interpreter has clearly not changed. It still points to /lib64/ld-linux-x86-64.so.2, which doesn’t exist on NixOS (and is the core of the incompatibility problem). Probably a mistake with your patchelf invocation, did you read the “Starting Point” section and have stdenv.cc in your environment?
Having that path on your distro is inherently impure, since it introduces an un-versioned dependency into all your binaries, which is at the very core of what NixOS tries to avoid.
You’ll run into this a lot if you expect random binaries to just work™, unfortunately. Nix by definition clashes a bit with inconsiderate upstreams, it is just different from Ubuntu 16.04 and explicitly doesn’t try to support binaries built exclusively for it. While I understand the frustration, there isn’t really a way to change this without giving up the ideology behind NixOS, at least not until more projects provide nix flakes. It’s best to stick with pre-built nix packages where possible.
But hey, I know very well that that’s not easy. So let me cover your options:
The “correct” way of doing this would be to override the version of the package, by doing something like this:
jabrev_master = pkgs.jabrev.overrideAttrs(old: rec {
version = "5.4";
src = fetchurl {
url = "https://github.com/JabRef/jabref/releases/download/v${version}/JabRef-${version}-portable_linux.tar.gz";
sha256 = ""; # Update after nix complains and tells you the sha
};
});
You should be able to add that snippet in a let block, and replace your jabrev with jabrev_master wherever you would otherwise install it. That said, this only works for upstreams whose build processes aren’t too complex and don’t change too much.
If it is more complex than that, you’ll need to look at how the package works, and fix the build instructions, at which point you might as well upstream your update. And then you’ll contribute to NixOS, and hopefully make it easier to use the things you care about for everybody else 
The second option is an “fhsUserEnv”, which is a bit like a sandbox or a container in your NixOS system. This blog post does it more justice than I can.
I’d call this the best option for getting a package running the quick and dirty way, but integration with your real system can be a bit limited.
patchelf. The really quick-and-dirty option. Clearly you’ve already tried this, it can be tricky to use.
Package with the autoPatchElfHook. A combination of the “proper” option and the one above.
This is more foolproof than patchelf, and it keeps your environment reproducible. It does mean you need to learn to write a package and not be too lazy to do so, though, which can be a tall order. It also doesn’t always work, particularly for naughty upstreams that insist on only working on a decade old Ubuntu version…
If all else fails, there’s always the nuclear option. Personally, I run into this problem rarely enough I haven’t even bothered to learn to use the fhsUserEnv, so for naughty upstreams where I need to mess with versions and custom builds (e.g. Bazel), I typically throw them in a ubuntu 16.04 VM, because it’s almost impossible to make them run anywhere else anyway.
You likely have your favorite VM software already, but personally I’ve found this a lot more viable since discovering GNOME Boxes, which makes this kind of thing extremely trivial.