Pretty much all Linuxes use GNU versions of the original core Unix commands like ps, which, as you've noted, supports both BSD and AT&T style options.
Since your stated goal is only compatibility among Linuxes, that means the answer is, "It doesn't matter."
Embedded and other very small variants of Linux typically use BusyBox instead of the GNU tools, but in the case of ps, it really doesn't affect the answer, since the BusyBox version is so stripped down it can be called neither AT&Tish nor BSDish.
Over time, other Unixy systems have reduced the ps compatibility differences. Mac OS X — which derives indirectly from BSD Unix and in general behaves most similarly to BSD Unix still — accepts both AT&Tish and BSDish ps flags.
Solaris/OpenIndiana behaves this way, too, though this is less surprising because it has a mixed BSD and AT&T history.
FreeBSD, OpenBSD, and NetBSD still hew to the BSD style exclusively.
The older a Unix box is, the more likely it is that it accepts only one style of flags. You can paper over the differences on such a box the same way we do now: install the GNU tools, if they haven't already been installed.
That said, there are still traps. ps output generally shouldn't be parsed in scripts that need to be portable, for example, since Unixy systems vary in what columns are available, the amount of data the OS is willing to make visible to non-root users, etc.
(By the way, note that it's "BSD vs. AT&T", not "BSD vs. Unix". BSD Unix is still UNIX®. BSD Unix shares a direct development history with the original AT&T branch. That sharing goes both ways, too: AT&T and its successors brought BSD innovations back home at several points in its history. This unification over time is partly due to the efforts of The Open Group and its predecessors.)
The term "userland" can refer to many things in different contexts, but here I interpret "GNU userland" vs "BSD userland" as the default, minimum set of programs that come with a distribution.
The big main difference is that the two userlands start with completely different source code. GNU cat source code NetBSD cat source code. Just from that simple-in-concept program, you can see that NetBSD's cat uses traditional, single-letter command line flags. GNU programs tend to have single-letter flags, but also the --something-long type options. GNU programs also tend towards POSIX compatibility.
That difference in source code will lend the two userlands different behavior in some cases.
It also looks like NetBSD (at least) uses its own version of libc, the standard C library. I'm getting in over my head here, but libc and dynamic linking are strangely inter=related. Again, different source code will lead to different behavior.
I think that as a shell user, you'd find that ps would act different, and ls might give you slightly different output than you're used to. You'd have to find equivalent command line flags for some programs, if you use the --long-option type of command line flags.
Historically, my understanding is that BSD userland descends more directly from V6 and V7 Bell Labs Unix, via the 32V port to VAX hardware. GNU userland is newer, written at least somewhat in reaction to AT&T's attempts to keep code a closely guarded secret in the early 80s. After the 1983 Bell System divestiture, AT&T tried to "monetize" Unix. Part of that was to license the source code in a way that prevented most people from ever seeing it. Richard Stallman and others had problems with this. Their GNU project existed specifically to create a freely-shareable Unix-like system.
In the meantime, by 1993, AT&T sued the University of California system over the BSD ('B' is Berkeley, where University of California is located) systems. People at Berkeley had replaced all of AT&T's original source with new code, and that new code became the ancestor of at least NetBSD's userland. AT&T and UCB came to a settlement in 1994, revealed to the public in 2004.
Naturally, at least ideas cross-pollinate, so there's at least conceptual similarity between GNU and BSD userland, but corner cases definitely differ.
Best Answer
No, there is not such a script.
You basically have 2 choices:
/bin/shdoesn't have to be conforming. The portable way to get a POSIX conforming shell is:PATH=$(getconf PATH) command -v sh