Of course not. People should have the choice on how and what they want to learn. I just disagree when choice is turned into equivalence (i.e. formal education providing no value over self-learning / disguising knowledge to build bird houses as knowledge to build skyscrapers).
In some cases (some people) it may not actually matter, but in the general case, looks like it does.
But isn't that why we're supposed to have "Junior" and "Senior" level positions? I think that what software development really needs is a loosely structured guild system where you gain rank not by attrition or seniority but by reputation, where you gain/lose reputation based on who you back for seniority and how well they do. It seems that beyond CS education, it's a constant learning process. You cannot make a career only with what you learn getting a degree in CS.
It's true that a degree in CS doesn't make a career, and that it's mostly a constant learning process. After a while the difference between having a degree or not having one is difficult to measure and junior/senior levels become defined by experience. But everything else being equal, the person with the degree will have forgotten a lot that the person without the degree wasn't exposed to in the first place. Many people will be exceptions to this, but I'm just talking about the general rule here.
Once you enter an organization, you build reputation there. This is the only thing that matters. To transfer this reputation between organizations, the organizations themselves must recognize the transfer (a form of trust). When you have long and convoluted interview processes, it means there is no such trust. The organization you are trying to join is basically starting from scratch in evaluating you skills, disregarding infomation that says that even if you can't balance a binary tree now, you once did and so can do it again if required.
University degrees are supposed to provide this information. They provide knowledge but also provide a path that is known to be difficult and with a known level of "reputation" once completed. Experience alone cannot possibly provide this, because work at company A says litte to company B if the inner workings of A is an unknown quantity to B.
This is the theory at least. If universities aren't doing they work properly, this whole system collapses.
That said, had a similar issue with logic in a simulation software where each virtual unit was its' own OO based object, with it's own threads for events... could only run about 4 simultaneous simulations on a server, and it still would bottleneck (GC was horrible). change it to a single event-loop that signaled each unit, and most of the concurrency issues went away. Streamlined the message passing (more functional approach) and memory usage dropped a lot... couldn't convince the manager to switch away from an SQL backend, which was the final bottleneck (normalized data structures), as it was then fast enough.
Had another instance where a configuration table from a database was loaded into memory (for performance), but then was kept in memory as a DataTable, with text based queries for each access for each key, that happened over a thousand times in a single web request (logins were taking too long)... Changed it to a HashTable, and lo and behold, concurrency was no longer a problem... similar issues with not understanding how static variables worked in a multithreaded application... OO ftw again (sarcasm).