Why is Linux "Unix-like" if its kernel is monolithic?

I believe the answer lies in how you define "Unix-like". As per the wikipedia entry for "Unix-like", there doesn't seem to be a standard definition.1

A Unix-like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the Single UNIX Specification.

There is no standard for defining the term, and some difference of opinion is possible as to the degree to which a given operating system is "Unix-like".

The term can include free and open-source operating systems inspired by Bell Labs' Unix or designed to emulate its features, commercial and proprietary work-alikes, and even versions based on the licensed UNIX source code (which may be sufficiently "Unix-like" to pass certification and bear the "UNIX" trademark).

Probably the most obvious reason is that UNIX and MINIX are antecedent of Linux, having inspired its creation.2

Torvalds began the development of the Linux kernel on MINIX and applications written for MINIX were also used on Linux. Later, Linux matured and further Linux kernel development took place on Linux systems.

Linus Torvalds had wanted to call his invention Freax, a portmanteau of "free", "freak", and "x" (as an allusion to Unix).

Whether a system is monolithic or microkernel does not seem to be considered when calling an operating system "Unix-like". At least, not nearly as often as whether the system is POSIX-compliant or mostly POSIX-compliant.

The "UNIX way" really refers to experience of the user. A small set of utilities can be combined to build an effective operating system command line. Related to this, operating systems utilities are in no way "special" or have power beyond programs which you can write yourself.

This is a difficult point to make these days, since UNIX was so successful in this aspect that it has become the way operating systems are expected to present their command line interfaces. The point is best illustrated by a counter-example: here's how to do cp a.txt b.txt on a IBM mainframe:

//COPY     JOB ,CLASS=E,MSGCLASS=X,NOTIFY=&SYSUID
//cp       EXEC PGM=IEBGENER
//SYSIN    DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSNAME=a.txt,DISP=SHR
//SYSUT2   DD DSNAME=b.txt,DISP=(NEW,CATLG),UNIT=SYSDA

This won't even copy every type of file.

UNIX made a number of assumptions which simplify usability at the cost of performance. File channels 1 (stdin), 2 (stdout) and 3 (stderr) go to and from the terminal, removing a lot of the boilerplate from the JCL above. The filesystem supports one type of data -- bytes -- and one access mode -- sequential (although the pointer where the sequential data can be read or written can be moved to implement a sort of "random access"). This means that system utilities only need deal with one type of file and one type of data to cover all files and datatypes. The filesystem does not require pre-allocation. Adding files to the directory (aka "disk catalog" on IBM mainframes) happens automatically if the filename is known to the operating system.

These assumptions were so successful that these days we don't even give them a second thought. Whereas at the time they would have appeared profligate -- imagine the sheer overhead of a filesystem which wasn't told in advance the maximum size of a file.

But UNIX didn't stop there. It promoted a "toolbox" approach to system utilities. The mainframe's IEBGENER can print files, rearrange fields within records, drop records, create blank records. In contrast, in UNIX cp copies files, cat lists file contents, cut handles fields. There's a neat syntax for stringing the stdout of a command to the stdin of the next file, all on one terminal line. Using this "pipe" syntax and those small commands we can do everything which IEBGENER can do. And things which the authors of IEBGENER never dreamed of.

Kernighan and Plauger wrote an influential book in 1976 about this approach -- Software tools -- and that's really the first exposition of the "UNIX way". Kernighan and Pike restated this approach in their 1984 book The UNIX programming environment.