This might not be exactly what you're looking for, but it reminded me of something I've seen a lot of people not know -- figured I might as well share (assuming Windows, not sure if applicable for other operating systems):
In most text editors, Ctrl will change manipulation to be word-centric instead of character-centric.
Ctrl + Left/Right Arrow will skip to the previous/next word. Can also be used in combination with Shift to quickly select/deselect whole words at a time.
Ctrl + Delete will delete from the current position until the end of the word.
Ctrl + Backspace will delete from the current position until the beginning of the word.
The optimizer will see this for loop. Notice that there's absolutely no need for this for loop as it's just iterating and adding. This is an absolutely redundant piece of code. When the optimizer makes it's edit the code will look like this.
int a = 29
Just needed to correct this -- a would be equal to 30 in the given example, not 29.
But I prefer globals because the code seems clearer when the functions take no arguments.
This is something you should unlearn as quickly as possible.
While I can see that feeling cleaner, consider the fact that anything, anywhere, at any time, can access and modify the variables.
As the project you're working on starts to grow, this will become a problem. Suddenly, the variable isn't what you expect it to be, and finding out why is extremely difficulty and time-consuming.
On the other hand, if you pass the variables you need into a function, you can follow it a lot easier. You won't pass lots of parameters that aren't used (because it's tedious and boring to pass everything all the time), so you'll end up with functions of code, for the most part, only take the parameters they actually need.
Globals are bad.
There are some exceptions (e.g. globals that are read-only aren't as bad), but for the most part you should stay away from them unless you have very very good reasons not to.
3. Real-time combat, at least, it can do. In fact, I reckon it'd be a lot harder to do turn-based combat in Unity than real-time.
Both are completly doable.
4. Now, I didn't spend much time in Unity last time I tried game development (I never got a team together, and moved to Unreal while I was waiting), but I couldn't find one person who could tell me how to give an object multiple hitboxes. And funny,I just got off Steam where I was trying an FPS made in Unity. Oddly, they didn't have headshots, a nearly universal FPS trope. Kinda makes me think multiple hitboxes is impossible in Unity, or at the very least is so hard to do that the devs of that game couldn't figure it out.
There's no issue with having more than one hitbox. You might have to use game objects which are basically just a hitbox and make it a child of the main object or something like that (first solution I can think of, probably better ones exist), but there's definitely ways to this. Lack of headshots in the FPS you played was not due to it being impossible in Unity.
5. This might not be impossible, but the entire system would need to be completely built from the ground up in Unity. There isn't even a basic framework present for the existence of stats. In fact, there's no framework available for any RPG mechanics. Or the mechanics of any other genre, really. That isn't a problem if you're making a simplistic mobile "game" that barely has any mechanics, but for a REAL game, you'll want a more specialized engine.
6. See above.
JTippetts covered some of this as well.
Like I mentioned, you will have to do some work on your own. There might be other engines which have more built-in solutions for specifically these problems, but I think they are lacking in some of the other departments. I would also say there's a high chance of those engines not supporting what you need 100%.
Additionally, I object to the "for a REAL game" part.
Only if you have ignored literally every other word in the post.
What makes you say that?
Not everything you mentioned will have a solution built in, but everything you posted can be done in Unity.
There might be slightly better suited engines out there, although I can't personally think of any that fit your requirements better while not going against other requirements you have, but Unity is certainly a valid choice.
"Lag" in this context is usually reserved for delays due to network latency. The main things here involve network speed & stability, as well as how much data you have to transmit between server/clients.
"Frame rate drops/low frame rate" is usually reserved for the game playing at a low frame rate. This can be caused by having too much performance heavy AI or calculations (CPU bound), or by trying to draw more than the client's computer can reasonable handle (GPU bound) -- or a mixture of the two. This will vary wildly based on the player's hardware. The only reasonable thing you can do here is set a minimum requirement, and test the game on that hardware. There are things you can do to help some of these issues (GPU especially), by allowing different render resolutions, post-processing effects, etc.
Asset load time would mainly impact frame rate, but there's not always a strict correlation. A game with a 2 minute loading screen can have better performance than a game loading for 1 minute.
Generally, it's hard to say "this will make the game too slow" -- a lot will depend on the actual implementation.
Set a target hardware, and test regularly on it. If the game runs too slow, use profiling techniques to figure out why it's too slow. Maybe there's code you can optimize to make the problem go away, or maybe you just need to make the assets more light-weight. There's no 1 true answer here. It will depend on what you have and what you're doing.