From what I know about Estonian eID stack, they use traditional PKI to the full extent -- LDAP, PKI, OCSP, all the standard designs from the 90ies and then internally (for use by the government itself) they have a sort of a document exchange system on top of that where everything is done through CMS (PKCS). I believe this is why eIDAS and trust services directive talk about trust lists, qualified certificate authorities and all that.
So you get a physical id card that is a smart card for X509 certificate and then sign, encrypt and do all the stuff you do with keys once you figured out key management. Since the key can't leave the card you need to deal either with a special Estonian keyboard that doubles as a keyreader (in Ukrainian flavor we get a mobile app that can generate a key and get x509 issued remotely, maybe Estonia has that too nowdays or we get a file-based key from a trusted provider, like a bank) or get an actual keyreader or a phone. On the provider side you also have to deal with trust lists, because Estonia and Lithuania don't use the same root of course.
The first gotcha is -- if you have LDAP, CSP and OCSP and can query those, that's a bit of a privacy risk (AFAIK, primary key is based on the date of birth, because reasons). Second gotcha -- key rotation is not practical, so certificates are long lived. Certificates that I saw had demographic identifier of the person as a serial, which is not great for privacy, but convenient for deployment I guess (for comparison, Ukrainian flavor only allows CSP through subject key and has the number deep in the directory lookup extension)
I don't think the stack is bad, but I think it's an overkill for the basic feature of logging into the government website and blessing some bytes with your legal persona. It does help when the user signs a legal document and then tries to walk it back (for example because the document is now an exhibit A in a VAT fraud case, yes real story). I think this particular problem can be solved by non-technical means. More specifically, PKI solves the problem of verifying the identity of the user and then allowing to prove to a third party that it happened.
What is actually needed from the ID stack is allowing a first party in a closed system to match the token presented by a second party to their legal identity. I don't believe cryptographic signing or key derivation is really necessary, as the system that produces the key and the system that verifies the signed artifact are the same entity in most threat models.
I think DigID does the right thing by being a glorified OTP generator with more or less nice UX that solves just that. The actual problem is key provisioning anyways, but once you have done that, it isn't necessary to go full PKI.
To make my point even more ahm pointy, we don't use client X509 to log into github or google. We use passwords, HOTP and fidokeys, because x509 has bad UX and bad security too (in practice)
Add: downvotes for explaining why PKI is an overkill? okay, I will not survive that