You can, but that's not the system certificate store.
Android has two certificate stores (the user store and the system store). The user store can be altered through the method you linked. The system store used to be part of the system image (you could always disable certificates, of course) and will now be moved to an APEX location that Google can update (to prevent the Let's Encrypt issue in the future).
To alter the system store, you need root access. At the moment it's just a matter of dropping a file with the right name and encoding at /etc/system/cacerts (through Magisk style overlays, or by modifying the system image) but that will change soon.
What's the practical difference between system store and user store? Do some apps or system operations only trust the system store and not the user store?
The user store is a certificate store that the user can add certificates to. It used to be the case that by default apps would get certificates from both stores if they asked the system for certificate authorities to validate against, with the option to opt out of specific stores, but this changed years ago. Now apps need to opt into loading user configured certificate authorities.
The system store, located in /system/etc/cacerts, is baked into the system image and can't be altered without root. The user store, located under /data, can be updated from the phone's settings.
The system store is now the default store all apps use to validate certificates, unless they pack their own certificate authorities. Many apps doing certificate pinning will do that as well, which prevents them from being MitM'd without injecting code into them.
I don't know the difference between the user and system store, but I do know that apps can choose not to trust certs installed by the user and instead only trust their own that they bring with them. Was frustrated to find this when I was trying to MITM an app to see what it was up to on the wire.
Apps used to trust the user store by default, but that changed back in Android 7. Now they only trust the system store by default and need to opt into also loading the user store. So, it's not that they look at the stores and pick one, it's that the user store has effectively been disabled for most apps (browsers usually work, thankfully). Even Firefox for Android will only use the user store if you go through a five step process to open the hidden settings.
Some apps do certificate pinning, which basically only validates certificates against a specific certificate authority and completely defeats any system certificate store.
You can MitM these apps by injecting code to bypass their restrictions. The eBPF methid linked above works, or you can use Frida in root or rootless mode to inject a variety of existing scripts to defeat certificate validation. This is a lot more involved than installing a certificate authority, but it'll work if you want to reverse an app.
Android 7 lacked the Let's Encrypt root certificate, and could only use the Let's Encrypt protected sites because their original root CA was cross signed by another CA.
The cross signed CA certificate expired, so that solution stopped working. This meant that every app that connects to sites with LE certificates ran into HTTPS validation issues.
For browsers and other apps that opt into the user certificate store, the solution was simple: download the new Let's Encrypt CA and import it into the user store.
However, the system store, which all apps default to, couldn't be altered, because they were part of the ROM. That meant that every app that chose not to opt into the user-provided certificate store broke on Android 7 once the cross sign certificate authority certificate expired.
Many app developers don't know about these stores (or, let's be honest, about the details of HTTPS) and other apps explicitly chose not to opt in. Before the expiration of LE, the user store was used almost exclusively for MitM attacks; some by nation states like Kazakhstan, some by people reverse engineering apps, others by stalkerware. There are apps that have to work with MitM interception for certain businesses (for example, because of regulations regarding secrets) but those will usually be aware of the issue and provide an opt-in if they want to keep that customer.
That's why Google opted to make the user store opt-in in the first place. This broke the workflow of people like me, who run their own internal CA, against better judgement, for stuff like home lab servers.
So, in short: a security measure combined with manufacturers dropping support for their phones after ridiculously short amounts of time meant that Android 7 users couldn't access tons of apps and websites.
Android has two certificate stores (the user store and the system store). The user store can be altered through the method you linked. The system store used to be part of the system image (you could always disable certificates, of course) and will now be moved to an APEX location that Google can update (to prevent the Let's Encrypt issue in the future).
To alter the system store, you need root access. At the moment it's just a matter of dropping a file with the right name and encoding at /etc/system/cacerts (through Magisk style overlays, or by modifying the system image) but that will change soon.