I'm not sure what your level of understanding is, so I'll write this reply in a way I hope the average reader can follow, though I assume you'll know most of this already - I hope I don't come across as condescending.

TL;DR: the topology of these curves is quite different over finite fields.

I first encountered what I consider cryptographically unhelpful drawings/intuition when I studied lattice-based cryptography. There's a whole field where a fundamental hard problem is finding the closest vector to a point not on the lattice. If you try and explain this by drawing a 2 or 3-dimensional example over the reals, anyone who's paying attention and proficient in Linear Algebra will ask themselves, why don't you just transpose the whole thing and then take the orthonormal projection? The problem is that in a finite field, unlike over the reals or complex numbers, orthogonal projection doesn't get you any closer to your target, so the intuition over R^2 is in my opinion very unhelpful to understand exactly why SVP/CVP are supposed to be hard, and indeed had me confused for a while until my professor pointed out I should forget "the silly drawing over R^2" which he didn't like either.

For Elliptic Curve Cryptography, I find the example of a curve over the reals again misses the point of why exactly problems like DLOG are hard - for discrete-log based crypto at the 256-bit security level over finite fields, you need an about 15k bit modulus depending on which site you look at (NIST 2016 at keylength.com is a good place to start) due to speedups from Number Field Sieving etc. THis is the kind of structure that I mean you don't get.

On EC, to get 256 bit security you need exactly 2 * 256 = 512 bits of key (slightly oversimplifying, the factor 2 is because you get the "sign of the y value" for free). The number 512 pretty much stands for the conjecture "there is no other cryptographically exploitable structure to take DLOGs over these Elliptic Curves". In fact it's not just "we haven't found any such structure" but there's an argument about heights of points (Miller '85 I think - though I'm pretty sure I've also read something by Koblitz on this) why on certain kinds of curves such structure is unlikely to exist. (Of course, other kinds of curves for fancy bilinear group stuff exist and do have more structure. And supersingular curves are another topic altogether.)

The structure you obviously do get is a group, which you can extend to a vector space over the finite field so that (x \mapsto xP) is a linear function. The security property you want is roughly "you get this group, but only this group" (and the "sign", so add 1 extra bit to your keylength) and there is no useful concept of anything like points being close to each other, continuous maps in the usual sense etc. Plot the points on an EC over a small finite field and it looks like a random scatterplot rather than a neat and elegant curve - which is the whole point of using ECs over finite fields for DLOG-based crypto.

I found your comment interesting, especially the Miller '85 reference. You certainly don't come across as condescending, so don't worry about that.

You are of course right that extra structure helps with solving DLOG. I was hoping that you could point me to some specific reasons why DLOG is easier on real/complex curves. I'd be very interested in learning these.

I don't find a "nice smooth curve vs. scatterplot" argument very convincing by itself -- you only care about a cyclic subgroup anyway. Take a complex elliptic curve, viewing it as a torus consider its fundamental parallelogram, and plot a cyclic subgroup on this parallelogram. Won't you get a nice scatter plot just the same?

Even if you can use this extra structure to find some more efficient DLOG algorithms, you could try to apply the same solution as with the crypto based on multiplicative groups of finite fields: just use larger points. My understanding so far is that the reason we don't do it is purely computational efficiency -- I'd be very interested in learning any reasons to think the contrary.

And, back to the original point, I think that the drawings of real/complex curves are very helpful when learning the basics. The group law is really best understood if you actually draw some lines intersecting the real affine part of some curve, show what happens when you draw a tangent line etc. If you confine yourself to finite fields, while it formally works just the same, the geometry is much less obvious, and talking to beginners about Cartier divisors and line bundles won't help much.

While the finite fields are the whole point of elliptic curve cryptography, they are definitely not the whole point of elliptic curves, and in fact I believe that complex case with all the extra structure is best for educational purposes.

I'm afraid I don't have a neat answer to why your first question. I did find the Koblitz paper I meant earlier but it's more about why one particular attack won't work: https://link.springer.com/article/10.1007/s001459900040

There are other reasons beyond efficiency why I would prefer people to switch their DLOG crypto to EC in practice: it's hard enough to implement - even with introductory blog posts with images - that your average developer leaves the details to an expert. libsodium for example is very well designed and written and few people think "I know, I'll write my own Curve25519 implementation" but lots of people seem to think that they understand finite fields well enough to build crypto, after all they have a bignum library and a modexp function, what could possibly go wrong?. I've seen finite-field discrete log software that is supposed to be production ready with the following problems:

  * Non-constant time implementation of "schoolbook" square-and-multiply. 
  * Forgetting to check if points really are in the group, e.g. you're supposed to be working in a q-order subgroup of Z^*_p where q | (p-1)/2 but the software accepts any integer less than p as a group element. 
  * Crash or infinite loop if you pass 0 as a "group element".
  * Parameters can be specified or overridden by the sender of a message and set to tiny values.
  * Not checking whether the modulus is prime.