Opinions are like a-holes; everyone's got at least one. So here's mine: By all means go ahead and learn C (and C++) on a MCU.
While it is a reasonable argument that debugging in a PC is "easier" due to the much more resourceful environment and while it is true that a PC programming environment is much "richer", in the end you embedded code is going to have to work in an embedded environment. To me it has never been worth the bother to maintain 2 distinct environments with their separate issues and differing practices. With C and especially C++ it is the case that for embedded development you don't actually need ( or want) to learn the "full" language with all the runtime candy available for regular computing environments. The habits and ways you learn in those environments are not fully repeatable in embedded environments and if you do proper development then you anyway need to come up with ways to QA your code in the final environment. Conversely, learning the hands on practice of debugging arbitrary code fragments in the embedded environment with proper HW support is precisely what you will need all the time while doing the actual thing. I'm sure many PC programmers don't really know how to do this and how easy it is once you get the hang of it. And you _will_ get information that is totally unobtainable in the PC environment. So why bother doing it twice, more or less?
I do grant that in case you have a ready to go PC programming environment, it will facilitate development of "pure" computing code without reference to specific embedded peripherals or I/O.
As to debugging, just one suggestion: invest in the best debug support you can afford. You mention you got the latest ICE from Atmel and that should work. I have the old JTAG ICE Mk II and ICE 3 but those have been unused since i started ARM development and acquired a Segger J-Link to debug that environment. It is pricey but will do "anything", unlimited breakpoints included. Zero issues debugging code with Atmel Studio + J-Link combo (J-link of course supports all/most common tools and mfgs).
Do bear in mind that in at least one respect software production is like playing chess: While the rules of piece movements in chess ( / the syntax of a programming language / ) are rather simple, the strategy and tactics to win a game ( / program architecture, structure and application of formal algorithms / ) can be very complex, mentally demanding and subtle. The skills of software architecture and design are separate from the skill of writing code in a specific language. A good architecture and design are only loosely coupled to the environment at hand. As much of it as feasible should be abstracted above the actual hardware and that part is the one you can profitably develop and debug in a PC environment.
There are some obvious skills a _programmer_ should have apart from knowing the syntax of his/her chosen language(s). Anyone who has created an embedded piece of code knows something about the embedded peripherals (well, maybe not all of the Arduino crowd...) so i won't go into that here. For those majoring in CS the following is a no-brainer but many embedded code developers come originally from other walks of life and may not have encountered these so here is my list. It is not the idea to cram all of these in one piece of code but at least one should know they exist, so as to be able to learn more when needed.
Others can add their favorite skills if i miss something obvious:
*Fundamentals:
- basic data structures:
--arrays (dense, sparse),
--lists (singly and doubly linked),
--trees (esp. binary trees),
--stacks, bags, heaps
- basic sort and search algorithms
--bubble sort, quicksort,
--binary search,
- dynamic allocation (and the risks of it),
*Multitasking
- the concept of computation context,
- context switching,
- interrupts; interrupt context,
- interprocess communication:
--queues, pipes,
--semaphores, mutexes
*Interfacing:
- information hiding,
- abstraction (esp. hardware abstraction),
- signal conditioning (esp. for physical interfaces),
and so on ad nauseam... more advanced concepts such as numerical and seminumerical methods and algorithms &c &c. _These_ can and should be studied outside the embedded environment.