Execute the following code and report the error please:
import RPi.GPIO as GPIO
import sys
# Initialize I2C Bus
import smbus
bus=smbus.SMBus(1)
print( bus )
bus=smbus.SMBus(0)
print( bus )
Here is what I get…
pi@raspberrypi:~ $ sudo python
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import RPi.GPIO as GPIO
>>> import sys
>>> import smbus
>>> bus=smbus.SMBus(1)
>>> print( bus )
<SMBus object at 0x7f9be85d30>
>>> bus=smbus.SMBus(0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory
>>>
Sorry for be franky 
: But test with python is pointless as long the MCU (0x1a) is not detected/connected to the bus, because smb == I2C. The commands i2cdetect, i2cget, i2cset are more near to kernel implementation than the python modules. That was the reason I made that check list for @SJMarty. There really seems a hardware issue at the pcb. If the I2C modules wasn’t loaded, then the I2C commands would had thrown error and wouldn’t report other addresses. And the crosscheck of @NHHiker has confirmed, that recent kernels seems not initiate a new issue with the I2C drivers.
Maybe a bad soldering point at the connection to MCU I2C pins or something like that. It’s seldom that the MCU dies, if there was no additional force like electrocstatic discharge or something like that.
Or do you have inserted some additional lines to config.txt, which manipulates the I2C bus speed, like overclocking? I wouldn’t assume such things during troubleshooting.
The only thing that can change over time is the battery of the real-time clock, which can cause problems if the MCU relies on it. Therefore, it makes sense to check its condition and temporarily remove/replace it - if possible with the EON.
Thank you for all of the assistance.
My config.txt is generic - no overclocking or bus speed changes.
It appears that the issue is somewhere in the hardware as the MCU (0x1a) remains undetected. With no response from Argon Forty support in this thread, I have contacted them directly for support (request is #14328). Hopefully, I can purchase the part(s) necessary to get things running correctly again as in its current state, my EON is not usable.
Actually it was helpful, as I wanted to be 100% sure there was no possibility of an error at that level, as the errors being thrown later resemble lack of privileges…
It was not my intention to distract from your attempt to troubleshoot. I just wanted to prevent you from wasting any more time in the hope of getting it to work by changing the software.
Regarding the permission issue:
Your traceback message looks like rpi-lgpio is in use now.
rpi-lgpio is the replacement for RPi.GPIO. But it’s not really a own implementation, it’s a wrapper to emulate the RPI.GPIO API and uses lgpio internally. lgpio makes some trouble if you start the script from a working directory which is not writeable!
Also the ressources are not freed, if the python script was “killed” instead of terminated graceful. This can trigger the GPIO busy message without a second process running, especially if you use gpiozero this can happen after every exit of the script. I can recommend to use lgpio natively until gpiozero is fixed.
Because of such known culprits, I prefer the option with the least number of additional layers for troubleshooting the hardware state. 
If someone is reading this for the first time:
The I2C bus (smb) is responsible for communication from the RPi4/5 to the microcontroller unit (MCU), on the printed circuit board of the case, to control the fan speed, real-time clock, OLED. The GPIO pins, which are controlled via rpi-lgpio/lgpio etc., are the independent second part and are only needed for a simplified return channel MCU → RPi4/5 to signal an event, such as “Power button has been pressed”.