The time it will take to wire the inputs / outputs and then program the logic. I do not think that you would save much after a cost analysis.
I also agree with Steve. Troubleshooting would be much harder.
I/O is inexpensive.
I have Very Limited IO RTUs and even then I'd rather do some modbus comms to another old Controller than multiplex, but it is possible if you are limited. Just remember that if it's analog you need to freeze values and know which one is current. and such. but yeah that's the other think is when switching fails. you almost want to save an it put. to prove that it is switching lol.
Good point- if one of your PLC outputs fails, instead of an output simply failing to energize, your BCD or multiplexer will interpret it as a different command and possibly turn the WRONG output on. I'd rather not have my initials on that drawing..
It's already multiplexed one time before hitting the I/O.
Back in the days with lots of BCD thumbwheels and 7-segment BCD displays we used to do multiplexing and then it made sense.
If you have 10 thumbwheels you would use 10 outputs and 4 inputs and scan each thumbwheel by setting the corresponding output.
For ten 7-segment digits you would use 10 outputs to address each digit and then 4 outputs.
If you needed a more complex HMI interface you would make your own program in MS-DOS with an EGA or Hercules graphics card and connect a PC to your PLC over the serial port, using whatever proprietary protocol the PLC had, to read and write values. Turbo Pascal was da bomb back then.
Here is my opinion, for what it's worth. I'm sure it is doable but it doesn't appear to be practical or economical. I think it would require a lot of extra programming and additional hardware to encode the BCD going into the PLC and to decode the BCD coming out of the PLC.