It was both available without strings (unlike Minix), and yes, performance, though the performance was less because of microkernel vs monolithic, and more because Linus cared about performance and Tanenbaum really really didn't as far as Minix 1&2 were considered - they were "educational" systems and not a serious contender.
I haven't read this specific link, but I remember few chosen quotes about how Minix had no "multithreaded VFS" while Linux's monolithic approach meant one was available for free (minus locking).
To make it more accessible (because when I first read that comparison I didn't grok it either), the issue is that Minix filesystem server was single threaded and handled one operation, one by one. Linux VFS mechanism (and all "basic" operations triggered by syscalls) run in the thread of the user process that calls them. This means that I/O on minix was starved on single queue of a separate process with effectively no preemption, while on linux at worst you'd run out of scheduler quanta and be descheduled when the VFS op finished instead of getting immediate answer.
This is also why BeOS/Android Binder and Solaris (and Spring) Doors system provide multiple threads to handle incoming requests, with Solaris/Spring also "patching over" one's context to minimize amount of work involved in switching them.
Being free as in beer and compatible enough with the incumbent UNIX ecosystem to gain initial traction is a big chunk of why Linux won. Giving something of value away for free is extremely hard to compete with.
The other part is the UNIX server manufacturers falling behind on performance versus Intel and their fab prowess and AMD with their x86-64 architecture. Sun Microsystems went from being the second highest market cap in tech in 2000 to being bought by Oracle in 2009.
I think the GPL had a lot to do with it. Corporations are risk-averse and don't like to open-source things. "Our competitor contributed open-source code to Linux, we can too" is an easier sell than "We think our competitor forked FreeBSD, but we're not sure, but we should do the same and release the code".
Huge (32gb) git repo full of junk and small files. No power to change it. Created a cron job that updates and rebuilds every 24hrs. Clients can clone it instantly with overlay instead of a 30m checkout and build each time. Not to mention disk space savings