"Creates large pull requests". This also depends on the codebase. For example, some refactoring can't be half-done, so even one single refactoring can cause large pull request. I'd put it more like "creates bloated pull requests", meaning, larger than necessary. Number of changes to the code can go down with the code review. And this is not a sign of inexperienced developer - just that together with code reviewer there is more experience.

"Tries to work on a lot of tasks". In itself it's not a problem: Some tasks require background thinking and planning. I agree to description of the point though.

"Refrain from getting into an argument over disagreements."

Does it mean developers should never question or disagree? There may be different causes for the disagreement. Sometimes it's the right thing to question architect's decisions, provided there really are good reasons.

This point also depends on the overall team. Too quiet and agreeable team may mean more trouble. Culture dependent.

Hyped technology point. This has a subtle line. Interest in all new technology is not a problem. The problem comes with premature adoption of the technology - this is what really comes from inexperience.

Overall, it's probably worth to note, that every developer is inexperienced in the beginning of his/her career. And the greatest sign of that (from outside) is that they work much slower, produce buggier or at least more verbose code, do not fully understand what they are doing at times. And it may be ok while they are learning. So this article rightly does not include these signs.

This article is not about how to spot an inexperienced programmer, but what learner should pay attention to to stay on the right path to the mastery (and the list is far from being complete).