Just my opinion, but I wouldn't want to use an AVR for anything that connects to a network and with all the requirements you have stated.
Yes it could possibly be done with an AVR based processor, but due to the internal design of the AVR you really have to wonk up your code to use const data since the AVR processor cannot directly access the flash.
You also say:
- Needs to be able to operate in an environment alongside many others of itself. Up to 128 units at a time.
You are now talking about a very large system.
For something that connects to network, i'd be looking at something that easily interfaces to a network and has lots of network based tools already available.
The AVR, IMO, is not good at doing network stuff since often network stuff can involve const data or things like html pages or possible files.
I'd go with Wifi vs cabled ethernet since ethernet requires lots of wiring. With Wifi, all you need is power and drop things where ever you need them but when talking about 128 units doing all that you mentioned, that may be quite a large area and need repeaters but even using repeaters is still simpler than wiring up ethernet cabling and all the needed associated hubs and/or switches.
Also, long runs of ethernet can potentially induce voltage from things like lightning so that must be taken into consideration.
In terms of how to pull it all together, I'd look at some existing Automation platforms like openHAB, IFTT, MSQTT etc.... That will provide a good starting point and there are literally thousands of plugins for lots of devices and interfaces that already exist. So you don't have to write all the glue or user interface stuff to tie everything together. You can even interface it to alexa.
Things like the Raspberry Pi zero W would be great for higher level functions/features since you have a full linux OS and all its development tools (including python if you want to go that route) available along with built in wifi.
Things like the esp8266 based boards are nice because they have megabytes of flash, and tons of ram along with wifi to provide plenty of room for code. There are even boards like the Linknode that are UNO form factor which in some cases is beneficial
as it can use many UNO shields. One issue with shields is that many are 5v while the esp8266 is 3v.
The esp8266 can even use part of the flash as a file system for things like web pages, configuration storage, icons, etc....
There are lots of example projects out there using the esp8266 including many automation projects and web based automation.
Neither types of boards of those have tons of pins but you will likely need some kind of separate boards for the i/o and power control anyway.
If those add i/o boards are using SPI, i2c, or modbus, etc... you may not actually need that many i/o pins.
I think at this point you really need to carefully define your actual requirements and think about the overall design.
What you have now seems pretty lofty and you may be able to eliminate some things.
I.e. make sure to distinguish be the needs and the wants so that if necessary you can pair things back.
You also need to consider the overall design and architecture and how it needs to work in your environment.
i.e. you could have lots of very simple/dumb little devices that only do what they are told and can report status for a sensor when queried or you can have more intelligent devices that are designed for specific functions or have to be configured.
Personally, I'd tend to lean to the many simple/dumb devices but that is not knowing your specific needs.
You then have to think about real life things like power outages and/or communication issues.
i.e. if the power goes out, or you lose communication, do bad or even potentially life ending or fatal things happen?
This can affect your design as well.
For example, if you loose communication to a device that turned on a heater does the heater keep running and potentially create an issue?
Lots of things to think about.
--- bill