For me, P vs NP is a very clever bit of theory, and proofs of NP-completeness are actually kind of fun, but the more interesting question that it skirts is this

For me, P vs NP is a very clever bit of theory, and proofs of NP-completeness are actually kind of fun, but the more interesting question that it skirts is this: How do we talk about the speed of different algorithms? That's a much bigger topic, but usually a lot more relevant. If you're someone with code who's in a hurry, you benchmark as realistically as you can manage and hope you didn't flub the implementation, and that your data collection was statistically okay. If you're Donald Knuth, you define a simplified but somewhat realistic processor model and derive expressions for how much time your algorithm takes, and there's your answer. This is nice, but a lot of work, and it becomes positively nightmarish if you want accuracy on modern processors. If you're an Intro to Algorithms class, you look at the asymptotic complexity -- mergesort is O(n lg n), the (NP-complete) 3SAT problem is O(2^(n^k)) for some constant k, and so on. This gives good intuition a lot of the time, but not always. Insertion sort typically beats mergesort for small n, there are a lot of 3SAT problems that can be solved very easily, caches are all the time doing crazy stuff, and in general the world is complicated. We're interested in getting computers to solve problems in a reasonable amount of time; what are we to do? I know this isn't exactly an answer to your question, but I really wish that people had said more about this in college, and I wanted to talk about it.