So, until last year, icc had not been available for the majority of Linux's lifetime. And keep in mind, it would be foolish to jump to a compiler with little track record no matter how good it looks. It could vanish tomorrow or quality could fall fast once it gets a foothold if it is a for profit venture. Given that, it wasn't a viable choice on principles for the first few years (and after because it proved to be problematic).
It says something about longevity and continued availability that a simple google for gcc history gets a detailed page indicating 1st release, a description of the development and a roadmap for the future while history for the intel compiler disappears beyond 10 years back.
It has only been recently that there were GOOD options that weren't gcc. The Linux kernel has several tricky bits in it where the tiny details of the compiler matter including how ambiguous bits of spec are interpreted and how bits the spec leaves to the compiler's option. So given a choice between 2 credible free compilers (clang and gcc) and a very much not free compiler with a history of cheating (the AMD debacle is not the only instance), it's not a very hard decision to make.
Meanwhile these days in the embedded space, optimized compilation of the kernel in the embedded space isn't nearly as important as it once was. CPU performance in that space is growing by leaps and bounds such that if a general purpose kernel is appropriate at all, there is probably an embarrassment of CPU cycles available at least to the point that the differences between gcc and icc won't be a deal breaker. The target app might or might not be another story, usually not.
That isn't to say that optimization is at all unwelcome, just that it takes 2nd priority to the compiler being stable and readily available.
Icc (and more often, ifort) are more popular in the HPC area for the application. Usually nobody worries too much about the kernel in that space either since the big gains there are made in efficient coding at the source level rather than in compiler optimization AND most of the calls into the kernel will be for hardware bound I/O. Optimization matters more in the application where the CPU will spend the vast majority of it's time crunching data with (hopefully) good cache utilization.