I fail to see what's easy to understand about ASM in any sense.
Clear order of execution, lack of obfuscating abstractions, no need to worry about portability, language doesn't change, less hidden low-level details..
You can't tell what it does just by looking at it; you have to mentally break it down step by step.
I'll have to say that this is how I treat all programming languages.. high-level OO languages tend to be difficult to understand. It could be that some people are just naturally low-level oriented.. OCDs or whatever.. while the norm is to read everything fast and understand 10% of it, no matter what it is. It probably boils down to the difference between reading and understanding, in some philosophical manner.
ASM involves a lot of tedious shuffling into and out of registers, which has little to do with actually solving the problem you're trying to solve.
How exactly is this:
easier to understand, in any sense, than this?
profit = income - losses
Without knowing the languages in question, they are both impossible to understand. But I agree with you that the latter is easier to read.
As far as 6502 goes, your code example actually reminds me of BASIC. They are not terribly far from each other if you think about it. I barely read 6502 with nice variables like that.. disassemblies and the whole reverse-engineering perspective certainly make ASM look a bit worse than it is.
Assuming 6502, the former example is easy to understand because:
-it executes from up to down unless interrupted
-we know that A stores 8 bits
-all the instructions do a specific, well-defined, simple thing - no single instruction is difficult to understand
Memory references are the difficult part. We hope that they refer to some well-behaving albeit boring piece of memory. We fear that they are related to I/O or other places that the 6502 as a processor really doesn't know anything about.
With the latter example, I hope that there are no bugs, because even if it is "merely" C, which is a really nice language to read if written simply, I just don't know all the ways it can fail. If we assume a lot of things, it can be fairly convenient.. operating with well-defined variables and operators.
If we can forget about portability and undefined behaviour by using a "higher-level" language, we can probably think of variables and their operations in a more lightweight model - something equivalent to ASM. After some thinking the whole "high-level" vs "low-level" concept starts to crumble.
Still, a bigger language often means a larger selection of possible/typical lines/abstractions. Certainly at some point understanding starts to suffer if you cannot remember the language you're using. How much effort should be put to understanding the language vs using the language? If I had to understand one language out of the mentioned ones perfectly, I'd never pick C or C++ or Java, because 6502 is easier.