Stephens Answer already carries most implications, so this is merely an add-on.
First to keep in mind is that the 68k was way more in need of a cache than x86 CPUs, as its memory access was in line with execution, while the x86 prefetch buffer used 'free' cycles to read ahead, thus utilizing the memory much better than the 68k could do (*1).
Next, it depends on your processor structure to make separate caches worthwhile. Both CPUs use a single address space for instruction and data (von Neumann style) thus the simplest way (*2) to speed up memory access (*3) is to add a cache which operates on the plain memory interface without any change to the CPU. Caching that way is a feature of the memory system transparent to the CPU.
Regions that get accessed get cached into faster memory (*4) in hope of future reuse from there. That's what happened with the various cache designs for 286/386 systems. Simple and straightforward.
Now while a simple (unified; *5) cache is a quick and great solution, not all memory locations are equal. Most notably, instructions get reused more often than pure data. So if chip space is scarce (*6) and only a few bytes of cache are possible, then it will be better to reserve them for (hopefully) repeated instructions. That's the way Motorola went on the 68020 by adding 256 bytes of instruction cache.
Such a 'just instructions' cache isn't more complicated than a generic cache. The single difference is that data read access doesn't get cached (*7), everything else works the same. So far the 68020 did not bring a separate cache, but a partial one.
It was the 68030 that introduced a data cache of 256 bytes as well - plus adding a burst mode to read up to 16 bytes at once. Adding a data cache adds complications. Separating instruction and data cache is often described as Modified Harvard. While it's quite easy to add two separate caches on a true Harvard architecture, it's a nightmare for von Neumann style memories. Now each of the caches can hold the same data, so they must be synchronized with each other and memory as well.
Motorola's decision to go with separate caches in the '030 is more likely a result of keeping investment down. After all, the '030 is mainly a shrink of the '020, so adding a data cache (*8) on top might have been less work than redesigning the whole cache system. Also, since the added cache wasn't exactly large, keeping it divided it preserved the speed characteristics the 68020 already showed from its instruction cache.
When the 68030 became available, desktop 80386 systems were already sold with up to 64 KiB of cache. The sheer size of a more than 100 times bigger cache made Motorola's effort seem useless in comparison (*9). Intel kept the single cache for the 80486 (1989) but now integrated 8 KiB of cache right onto the CPU - which didn't stop mainboard manufacturers from adding external caches, now in the region of 256 KiB to 1 MiB.
Fact: Size does matter (and simply beats strategy).
As Stephen already mentioned, these designs were still good to feed the processing units of a 486 fast enough. So when the 68040 came around, Motorola just increased the size to 4+4 KiB cache with just little improvements.
While Motorola's strategy wasn't bad, it wasn't superior either. And Intel's switch to separate the P5's cache into two wasn't driven by some inherent advantage, but by 'need for speed'.
The 486es cache was 4-way associative, meaning each memory location could be buffered in any of 4 cache locations. To find the right location, the tags need to be compared; this takes time. by splitting the cache into two separate parts, this could be reduced to a 2-way system while keeping (in most cases) the same performance - but due to the less complicated hardware, its response time could be improved.
The basic idea of Intel's switch is not so much about specializing on instruction or data, but split the cache between two memory regions that (hopefully) overlap as little as possible, resulting in the same (lower) thrashing rate of a 4-way system but using the faster hardware of a 2-way system. Gaining a higher hit rate within instructions is a rather welcome side effect.
*1 - Motorola tried to counter this with a tiny cache in the 68010 realizing the so called loop mode.
*2 - After adding ever faster RAM.
*3 - Keep in mind, it only makes sense if the processor can handle instruction and data faster than it can be accessed from standard memory.
*4 - The stuff we couldn't afford for all of the RAM.
*5 - Isn't it strange to call something unified if it wasn't divided before? A great example of a retroactive definition we take as equal to its counterpart, despite the fact that it was only coined afterwards.
*6 - And it always is - just the magnitude changes.
*7 - Data write will still be used to update/trash entries, thus allowing to survive self modifying code or data and code intermingled.
*8 - And the MMU.
*9 - No doubt, it was a great benefit compared with the '020, still...