You're probably correct (I don't know enough about the junior applicant pool myself but I am going to speculate nonetheless), but 'cannot code' is vague, and I think this precise sort of vagueness creates confusion around: a.) What companies need. b.) What companies think they need. c.) What prospective programmers think companies need.
What companies actually need (or should need, if they're solving some problem), I'd argue, is people who are capable of solving domain problems in structured ways. This has everything to do with logic and almost nothing to do with 'programming' or 'coding' in the sense that I believe most people understand those words today. This is a skill that has very little to do with knowing xyz language, framework, or even paradigmatic abstraction and everything to do with having familiarity or mastery of both recent and ancient mathematical and logical principles (algorithms, data structures, computability theory, set theory, lambda calculus, etc.) Of course, the way we actualize these skills is through programming languages, but programming languages themselves are not the important part (at a high level).
I think a lot of hopeful and ambitious autodidacts unfortunately miss this, as the bulk of (I'd wager) free resources for learning 'how to program' do not do an adequate job of conveying the fact that programming is ultimately the application and encoding of abstract principles into a concrete solution for a particular problem domain. This effectively leads to a pool of job-seekers that are well versed in the latest lower order abstractions (as these are encoded in programming languages, e.g. iterators or a particular framework or paradigm) and not higher order abstractions (e.g. what makes a particular construct iterable, what structural properties suffice to assert 'iterability' of a set or structure, or e.g. how should one compare paradigms and select between paradigms for a particular problem).
At the end of the day, a lot of this doesn't matter. Most people in the programming field do just fine without diving too deeply into the heart of computability or information theory (some demanding positions in the field, of course, are exceptions to this). But I think if we want to produce better 'coders' an important step lies in disambiguating logical/mathematical/programmatic problem solving from the concrete practice of 'programming' (using a particular language with particular resources, paradigm support etc.) From what I can tell, University CS programs do an effective job at this (e.g. classes on algorithms and data structures and architecture are all distinct) but many free resources, I feel, do not. This may be the culprit in the production of that bevy of people who 'cannot code'--they can program, but they can't problem solve computationally or model problems well (I can't do this myself). And I think it leads to the following common realizations on a.) b.) and c.):
a.) Companies need people who can determine and analyze sets of potential structured/logical/computational solutions to problems.
b.) Companies think they need people who are good at using xyz tool in particular because xyz tool/language/paradigm etc. is popular, new, generally thought to be useful, etc.
c.) Prospective developers think they must learn xyz tool/language/paradigm/framework because companies seem to want that. They do so, never exploring the fundamentals behind xyz tool/language/framework and move on to learning the next xyz ././. next year to stay relevant.
The result is that many companies are bound to the solutions, abstractions, patterns etc. that xyz tool/language/whatever supports and thus they're actually quite okay hiring people who cannot really 'code'.
In truth you probably only need a few smarty-pants engineers behind the important stuff. The majority of folks can enter the workforce only having a basic knowledge. The ones that are curious enough will start to dig into the general/abstract principles behind computation and eventually learn enough to fill the shoes of the big boys. Most entry level programmers can get by just fine with a thirst for further knowledge, the ability to notice, adapt to, and use patterns that are already in place, and some very basic analytical skills. Of course, many hiring practices don't necessarily reflect this, which leads to the classic condition of "in the interview I had to show that I could do abcd with data structure xyz and implement algorithm hjk to solve problem p in t time but on my day job I just write against apis."
Disclaimer: I am not a programmer or software engineer. This is just my sense of the state of affairs as a curious outsider (I do work in the software field, but my job role is different).