IMO the way to study perspective (or any other artistic fundamental) is to live in the intuition-building framework, and take regular but relatively brief excursions into the strict-construction method. The point being to establish strict construction as a tool to aid intuitive construction and check your work,  moreso than vice versa. Keeping intent and concept -- what am I drawing? -- at the forefront, rather than method ('how am I drawing?'), to avoid the deadening of drawings you mention.

Arne's suggestion 'have some perspective-y lines, but they don't have to be ultra correct. Just use them as rough guides' hits the right balance IMO.

In regards to what essential operations in perspective it is good to train, I think Scott Robertson's book 'How to Draw' does an excellent job of paring down things to the most essential, combinable atomic operations.

Regarding spheres, Douglas Flynt has a step by step ellipse construction guide, using a quad-subdivision method.
If you want to construct spheres / ellipsoids out of rings (ie. the same manner in which Blender's UVSphere object is constructed), you can do it with just that (and perhaps a few slight nudges, given that in 6-point perspective, quads are often a bit curved)

Crits:

Most objects in your latest sketch look correct, but the lower face of the character's platform -- it isn't clear how it's oriented. The two smaller faces on the sides may contribute to this.

EDIT:
A drawing I made in between writing the above, using a freehand approximation of one of the grids you provided:

After fixing up this laptop, I was able to begin sorting through my backlog of scans.


(2b, hb, permanent marker)


(2b, hb)

The only thing I would add to what 32 said is:

Go outside pixel art. There are many important aspects of art that it's hard to pursue through pixel art. For example, muscles, anatomy and how form turns in general.

Ideally, you keep cycling through different mediums and restrictions. This is a way to keep experience fresh rather than becoming stuck in whatever beliefs/methods seem most convenient to your favorite media.

My point was rather: you can argue all day long about "Vendor B should have adopted Vendor A's choice, and made his product compatible", or the opposite. It will have no effect on how you adapt your software to work on both situations.

If this was intended to counter some of the points I made, then I want to be clear:

It's not that $FOO should have been standardized, though we live in hope

It's not that open source software is necessarily better -- although the code is often less overtly horrifying IME.

It's just that a platform that is made by devs for devs, where you can look into everything and see how it works, is naturally dev-friendly, and becomes more so over time. (the beginning in Linux' case actually being in Unix times -- culture of sharing and the whole cluster of ideas comprising "Unix Philosophy")
;
and conversely, a culture of black-boxing (Windows being the worse offender, but Mac should also be mentioned) - gatekeeping what you can and cannot do / look at - , is hostile to developers.  No amount or quality of tools can compensate for this; it's a systemic problem resulting in the devs simply not using the marginal platform, and thus not noticing the bugs specific to it.

(I also have experienced personally that GIMP and Krita are both a lot more buggy on Windows, so I thought it was relevant that they aren't buggy on Linux.)

Happy on their mountain, they think they know the one true way, the one ultimate eternal truth, smoking on the Dunning Kruger pipe everyday.

I must admit, I was tempted to just link the wikipedia article on Dunning-Kruger after reading enough of the thread. You have certainly shown more patience than me, being willing to do the research to find whether it's MSYS or Cygwin rather than just implying that part of the toolchain is missing.