True dependencies are actually pretty rare in most game logic, in my experience. If your update code is highly order-dependent you might consider using different methods that aren't so fragile.
In this rare case I have to strongly disagree with Apoch unless I'm miss-reading the intentions here or I'm reading more into the question than he was.. Everything is about order and in fact the OP is incorrect about Unity, there is order control built in, you can tell the engine the order of execution you want. Additionally, when it comes to the future with multi-core, without execution order control you simply can't effectively utilize current CPU's. (Well, not that I know of 'effectively'.) I don't disagree in that it *can* be fragile, but it is much like bad patterns in C++, you learn to avoid the parts that cause issues.
Having said that, let me rephrase it so the negatives have some context. Unity has ordering in terms that you can control which 'components' execute before other components. I think they call this the priority system or something like that. The purpose in Unity seems to be making sure that an AI update component can complete making decisions before any movement is calculated in that frame. This is fairly trivial common sense behavior I would think. But, perhaps, what Apoch was suggesting is that this is 'system' level dependency and not individual object to object relationship dependency. What I mean is that i always update AI before physics, I can apply impulses via the AI and have those acted on when physics updates, I never try to interleave AI and physics, this is *system* level dependency. The other, bad, option is that I write a follow behavior that executes at the same time as the AI for the object I'm following, well, which one updates first changes the behavior of follow since I could be following last frame or next frame's position. It's just bad news.
So, depending on the OP's intentions, dependency always matters. It depends on where you apply it as to if it is a problem or not.