Public-private key signing generally works like this
No, it doesn't. RSA can be viewed this way (if you stay at the 10,000 foot level); however a) using the same key to both sign and decrypt is not encouraged, and b) RSA is essentially the only signature algorithm that can be described this way.
However, that doesn't address your real question:
Hashing function signing
Well, you didn't describe it properly - for one, there's nothing to tie the message to the revealed key value. That is, someone could modify the message in flight, and the key value would still check out.
What Lamport is generally understood as:
We pick $k$ hash preimages $c_1, c_2, ..., c_k$, and hash each of them, and publish the result of each hash $H(c_1), H(c_2), ..., H(c_k)$ as the public key
When we get the message to sign, we convert the message into a series of values $b_1, b_2, ..., b_n$ (each value between $1$ and $k$) - this conversion is done in such a way that it is hard to find a second message that converts into a series of bits that consist solely of the values within $b_1, b_2, ..., b_n$).
The signature consists of the revealed preimages $c_{b_1}, c_{b_2}, ..., c_{b_n}$
The verifier can take the message and convert it into a series of values $b_1, b_2, ..., b_n$, and verify that each of the preimages in the signature hashes to the value within the public key.
It should be easy to see that forging a signature would require either a) finding a message that converts into values that are all revealed in the good signature (which we assumed was hard), or b) finding a preimage for a value that was not revealed (which we also assume is hard).
That said, your question really was:
I see that hashing/symmetric signing needs extra housekeeping
Well, Lamport is useful only if you need to sign a single message with a public key. When you look at blockchain (where we assume that the verifier an see all the signatures, and we can include the next public key in with the signature (and have the message being signed include the next public key, of course), this can work - it does, as you point out, require us to remember the next public key (which will change for every signature), but it's doable.
In many other contexts, this doesn't work. However, there are a number of modifications to hash based signatures that don't have these limitations:
Stateful hash based signatures (such as LMS and XMSS); these work like Lamport, except that a public key can sign a large number of different messages (and we can make this 'large number' larger than the number of messages we'll ever see). They do have the requirement that the signer keep track of state (which changes with every signature)
Stateless hash based signatures (such as Sphincs+); this eliminates the need to track any state while signing, and so acts just like any other signature algorithm
And, if you assume that RSA and hash based signatures are the only options on the table, well, they're not. There are also various lattice based schemes, multivariate schemes, zero-knowledge proof based schemes (Picnic) - there are a number of various options out there.
