GNU Grep's defense of its decision to ruin and then drop the 'fgrep' and 'egrep' commands is that these commands aren't in POSIX. There are a number of problems with this, but one of them is that Unix is not POSIX (and conversely, POSIX is not Unix). In practice, POSIX partially overlaps with modern Unixes, so just because something isn't in POSIX is not any sort of reason for a Unix to not have it (and never has been). Unixes have always had many things that aren't in POSIX.

(One obvious case where POSIX was less than Unix from the start is its omission of egrep and fgrep, which had been in all of the Unix families for years at the time POSIX was being written. The Rationale section of POSIX grep makes it clear that the people writing POSIX were fully aware of this and didn't care.)

POSIX is primarily a subset of Unix as of the late 1980s, with a certain amount of additional invention (some of which was good and other of which has been carefully dumped in a hole and forgotten). Not everything that we consider to be Unix is in POSIX, sometimes for good reason and sometimes not (this is true for commands, C library functions, the filesystem layout, and behavior). Since POSIX was mostly documenting (some) existing practices, it periodically made compromises or picked winners between the two dominant strands of Unix at the time (BSD and System V), and not all of those choices have proven to be particularly popular or durable.

(For example, your 'du' command almost certainly doesn't conform to POSIX in practice, because POSIX du reports in 512-byte units by default and it turns out no one likes that once they had a choice.)

What people consider to be Unix and expect from any Unix system goes well beyond what POSIX requires. A system limited to things that appear in POSIX and that behave as POSIX specifies would likely be thin gruel for most people (as well as behave in surprising ways). Consider, for example, the limited list of POSIX commands (which also include any number of commands that no common Unix implements today), or you can peruse the full Single Unix Specification for C functions and other items of interest.

(Also, a POSIX compliant system doesn't have to look anything like you'd expect from a Unix system. There's no requirement for POSIX commands to be in /bin or /usr/bin, for example (cf), and not really much requirements for what files and directories must be present. To the best of my knowledge, this was a deliberate choice on POSIX's part for multiple reasons, including allowing non-Unix systems to be POSIX compliant (cf).)