How long would it take the average person learn C++ to the point where they can confidently and reasonably use all C++ commands/functions etc

3-5 years, or more, depending on how much effort you expend on learning every nook and cranny of the language. That said, read on...

I'm just talking, to the point where they could create anything they're asked, even if it's primitive.

That's a completely different question. You don't need to know the whole of C++ to write programs with it - I'll go out on a limb and say that most people who use C++ don't know everything about it.

6 months to a year ought to do it, if you are fairly diligent about continually writing programs to expand your abilities.

how long would it take our average Joe... a primitive, but functional 3d engine

A lot longer. You need to learn a 3D API and a bunch of math, in addition to your programming language.

That said, write games, not engines is required reading. A "3D engine" should probably never be your ultimate goal, and it certainly shouldn't be your first goal.

I would like to chime in and address the second part of the question from my view point. Programming itself is more of a proper implementation and understanding of the way that a computer thinks. C++ or any language for that matter is little more than an instruction set that allows you to implement commands that the computer (or console) can act upon. What I see quite a lot of are people that read a book and they know some commands in the language but they don't always make the underlying connection of what the command is doing. For example (all be it possibly poor as I'm just making a quick reference example here..) In C++ many people learn to declare and reserve dynamic memory through new or memset methods, but very few actually understand what this is doing. The common and quick answer everyone will spurt out from memory is "It makes a dynamic variable in memory duh!"....

What is a dynamic variable in memory? Something that can be constructed and disposed as needed... Ok but what does that mean? ... It means that the computer is reserving a range of memory addresses in RAM to store a variable that could be of the size requested. And when you release or dispose of this dynamic memory the systems reservation of these memory sectors are made available for anything and everything else to reserve and use later. How about using Direct X for another quick example. There are many many many programmers out there that know how to use Direct X and if you ask them what it does they will answer (It renders graphics to the screen). Which actually is a bit of a false statement to be made. Direct X is an API layer that exposes command sets that allow you to activate capabilities of the video card's GPU hardware, shaders and on card ram (as well as many other features).

I'm sorry it seems vague but the point I am trying to make here is that learning the language is actually very easy. "cout prints text to the console", "if compares values" "for loops until it's end condition is met". The thing that makes a difference between someone being able to play with the language (and maybe even effectively produce some software) and the guy that can reasonably do whatever is asked of him is more the underlying understanding of the language actually causing physical things to happen on the computer and even some understanding of how the hardware itself works. This is the level at which you become more of a problem solver where in you know a solution you are aiming for, you can quickly think of the logic behind it (and in gaming / engine writing what the most effective use of the hardware may be).

So to the answers, how fast can the average joe learn C++? I don't know, how fast can you memorize a few hundred commands? How long will it take to elevate above that to the point where someone tells you "Make a thing to do this" and you can figure it out? That depends more on how long it takes you to make the connections between the commands your using and what they are actually doing not what the results they produce are. Especially when your getting into something like a game engine that requires advanced knowledge of hardware capabilities, hardware api's and advanced performance oriented design of the code. It's not just knowing how to use DirectX to render some geometry you need to make it "smart" enough to still work well when your users use it wrong.

This is why you can't really get a definitive answer on a time frame to expect. Everyone learns differently, many never make the underlying connections but they still get results, these people normally do better using someone else's engine and they can eventually get pretty good at it. However should you ask them to build an engine you'll start finding they will tell you "Um I don't re invent the wheel" or "Why? <insert favorite engine here> already does it good enough". This isn't laziness, more so this is actually the more experienced answer where in they may not know it but they are really saying "I don't understand how these things work I just know how to use them".

Just as a little more information as it would pertain to making an engine, here's the first few questions you should be asking yourself before writing a single line of code on an engine. "What is the most common video card type that PC gamers are using?" "What shader models are most common?" "What are the differences between the various sharder models?" "How GPU expensive are these various shader technologies on the most common video cards?" "What Direct X API's impose the greatest bottlenecks when attempting to trigger GPU calculations?" "What is the fastest and most efficient way to transmit the shader apps in to the pipeline?" "How can I manage my code to maintain lower bandwidth even when my users are trying to render a bajillion polies?"

I'm sure that many people will chime in after me on this and say that none of this matters. Compare their engine to Unreal. Why is Unreal so much more powerful? Is it because they use something that you don't? No it's because they address issues like these (and I do mean LIKE these maybe not particularly these). So all in all learning to "Program" and learning to use a language are different things all together and their importance varies based on what you are attempting to accomplish. When your not talking about games performance actually goes right out the window in favor of getting the expected result. Thus making it not so important that you understand how the language works just how to get what you want. However when you get into engines an the like the question is different. How can I leverage the hardware to get the result I am looking for. Amount of time for people to make these connections and actually start doing the proper research vary more than snow flakes, you are the only person that can have any idea how long it would take you to memorize the functions, learn how they make hardware level things happen and then making the connection between those and learning to solve problems. Basically I guess I'm saying learning the language is learning to get results using what is available. Learning to program is learning to solve problems. It's like detailing a car versus building a car, you can give anyone a sponge and a bucket and they can make your car look shiney, that doesn't mean they can actually make it go faster. So how long would it take the guy at the car wash to learn to make your car go faster? How long will it take billy anybody to learn to wash a car OR make it go fast?

Learning all of the commands/syntax in C++ is barely 10% of the battle. Really it comes down to logic and math, while there are certainly different paradigms used in different languages the process is mostly the same. Still C++ requires you to think about more of these simultaneously as it doesn't handle any of it for you.

Think of it like learning a musical instrument. You can learn all the keys/strings etc but you still won't be Aerosmith overnight.

I don't think this article should be used to smack people in the face who want to write an engine and I don't think it should be put on any kind of game development pedestal.

That's not what I use it for (nor what the article actually says, if you ignore your knee-jerk reaction to the title and really read it).

I'm merely pointing out a trap a lot of newcomers fall into, and sure, if the OP is purely looking for a learning exercise, then no one will stop him, but it never hurts to inform. If the OP had asked about "a primitive, but functional 3d game, something on par with say, the original QUAKE or Half-Life 1" I wouldn't have mentioned it at all...