I go back on forth on this one. Partly due to my professional bias, partly because many people get by just fine without it. Then again, a lot of people get by without being literate, but the degree to which that is culturally acceptable varies wildly.

I separate computer literacy into three areas: automation, coding, and reuse.

Being literate in automation means being literate enough with a machine (human or otherwise) to automate menial/repetitive tasks. For example, this is knowing about copy-paste, undo/redo, being able to use key commands to make a job faster (Ctrl-A rather than click+drag-for-years), or understating the concepts of "batching" or "macros" within a specific context. Automation concepts are much older than modern computing interfaces. I often find people who consider themselves computer illiterate but still maintain excellent process that lets them perform complex tasks quickly, repeatably, and with little error. However, the rigidity of automation also tends to damage people's psyches. They clutch to their coffee-stained, dog-eared process manuals, fearful of ever losing them. They will not deviate, and they will not seek a deeper understanding of a process in the event that it breaks.

However, simply being "code literate" is not necessarily taking on that deeper understanding either. Knowing how to read code, while daunting at first, is not incredibly difficult. Computer languages are designed with small, concise syntaxes so that the humans writing them don't have to keep too much in their little heads at once. They "encode" an idea using symbols and numbers in a specific order. If you can parse math equations, you can get a sense of code's purpose, and generally read all but the most exotic computer languages. However, that does not make you able to understand the task being performed by the code, why it's being performed, and how the solution was arrived at. And more critically: being able to read code does not mean you can write code that would be able to automate and solve a new problem.

However, as time goes on, it is rarer and rarer that a particular common problem has not been solved to some degree. There is a vast ecosystem of good software that can do a task and do it well. Having prior experience and knowledge of that existing software goes an incredibly long way. In the programming world they refer to this as "code reuse," but I like to think of it as playing with old Lego blocks. You don't have to make the Lego pieces, and the old pieces can fit with the new pieces just fine, so you can put them together to make something new. This requires knowledge of the inputs/outputs of the tinier pieces, and how to arrive at those solutions. Without that knowledge and experience, being unable to put those pieces together can put you way, way behind.

I agree that children should be taught on computers when they are young so that they aren't afraid to use them. At a minimum, they should be taught about automation so that they don't give themselves carpal tunnel or drive themselves crazy. They should know how to do most tasks, and have a healthy distaste for having to "do something manually." They should be exposed to code so they understand its purpose and its place. And they should be introduced to the existing, good tools so that their jobs are made easier.

The act of writing code, however, shouldn't be unduly forced on someone. Frankly, it won't take. Unless you're going for a STEM career. Then ya'll muthafuckas need coding. Be free of your Excel shackles.