Sorry if I was a bit ambiguous. I was not referring to the gigabytes of memory or even the abundant number of libraries when I mentioned that it is easier to program Raspberry Pis. Those are certainly factors, though I doubt that many embedded projects will exploit that much memory. In cases where they do exploit the resources, it is probably needed (albeit, likely at the level of megabytes rather than gigabytes).
I actually meant the Pis are easier to program since development can be self-hosted. Uploading a program to a microcontroller after each build is a royal pain in the bottom. Debugging (with a debugger) is also annoying, both from the perspective of setting up the software and having the necessary hardware.
With respect to laziness, I hold two points of view. I definitely agree the inefficient of resources should be viewed in a negative way. This is especially true when a solution goes from bytes or kilobytes to megabytes or gigabytes. More critically, I believe that laziness is a negative when the inefficiencies lead to less robust code. On the other hand, one of the chief benefits of computers is to reduce the burden placed upon people. Setting up a toolchain for microcontrollers can be nearly as complex as developing code for the microcontroller itself. That strikes me as wrong.
Aside: I periodically write software for microcontrollers for fun. One of my favourite exercises involves prototyping with high level code, such as using Arduino libraries, and rewriting it using increasingly low level code. It is how I approach learning a microcontroller, but I am also extremely conscious of both volatile and non-volatile memory usage. I am definitely sympathetic with your notion of avoiding laziness.
On the other hand, we should also realize that microcontrollers are often used because we are "lazy". There are many cases where microcontrollers are used even when a basic circuit can accomplish the same task since it is cheaper to throw an absurd number of transistors at something than it is to pursue more efficient solutions. (Labour costs add to project costs, along with the number/type of components, board size, the relative ease of iterating code verses iterating on board revisions, etc..) There are reasons beyond the challenge of generating the most efficient solution possible to consider because the efficiency of development is also a factor. As someone who pursues software and hardware development as a hobby, I often bemoan the state of affairs of commercial products. Yet I also realize that commercial development, or even the motivations of other hobbiests, leads to different perspectives.