It depends almost entirely on your specific game needs. It can work perfectly for a simple game, but fail on a more complex system. If it's working for your game, don't worry about it or try to over engineer it until the need arises.

As for why the simple approach may fail in some situations, it's hard to summarize that in a single post, since the possibilities are endless and depend entirely on the games themselves. I'll just give a few examples, but there are many other possible reasons and solutions.

For starters, I'll point out that updating your game objects and rendering them may have different requirements in some games, and therefore need to be handled separatedly. Some possible problems with updating and rendering game objects:

Updating Game Objects

Here's an excerpt from Game Engine Architecture which I would recommend reading:

In the presence of inter-object dependencies, the phased updates technique described above must be adjusted a little. This is because inter-object dependencies can lead to conflicting rules governing the order of updating.

In other words, in some games it's possible for objects to depend on each other and require a specific order of updating. In this scenario, you might need to devise a more complex structure than a list to store objects and their inter-dependencies.

Rendering Game Objects

In some games, scenes and objects create a hierarchy of parent-children nodes and should be rendered in the correct order and with transformations relative to their parents. In those cases, you might need a more complex structure like a scene graph (a tree structure) instead of a single list:

Other reasons might be for instance, using a spatial partitioning data structure to organize your objects in a way that improves the efficiency of performing view frustum culling.

It depends almost entirely on your specific game needs. It can work perfectly for a simple game, but fail on a more complex system. If it's working for your game, don't worry about it or try to over engineer it until the need arises.

As for why the simple approach may fail in some situations, it's hard to summarize that in a single post, since the possibilities are endless and depend entirely on the games themselves. Other answers have mentioned for instance that you might want to group objects sharing responsibilities together into a separate list.

That's one of the most common changes you might be doing depending on your game design. I'll take the chance do describe a few other (more complex) examples, but remember there are still many other possible reasons and solutions.

For starters, I'll point out that updating your game objects and rendering them may have different requirements in some games, and therefore need to be handled separatedly. Some possible problems with updating and rendering game objects:

Updating Game Objects

Here's an excerpt from Game Engine Architecture which I would recommend reading:

In the presence of inter-object dependencies, the phased updates technique described above must be adjusted a little. This is because inter-object dependencies can lead to conflicting rules governing the order of updating.

In other words, in some games it's possible for objects to depend on each other and require a specific order of updating. In this scenario, you might need to devise a more complex structure than a list to store objects and their inter-dependencies.

Rendering Game Objects

In some games, scenes and objects create a hierarchy of parent-children nodes and should be rendered in the correct order and with transformations relative to their parents. In those cases, you might need a more complex structure like a scene graph (a tree structure) instead of a single list:

Other reasons might be for instance, using a spatial partitioning data structure to organize your objects in a way that improves the efficiency of performing view frustum culling.