The terms "manager" as well as "system" are widely used. In general a "system" is a set of components that work together to fulfill a purpose (see software system and also self-contained system). In game development we often speak of sub-systems as parts of the engine like the graphics sub-system, the animation sub-system, the physics sub-system, ..., so grouping components by functionality. Moreover, we obviously allow (sub-)systems to exist in a more or less shallow hierarchy. I'm not aware of an analog definition for "manager". The term is often used when something is responsible for the lifetime of objects (memory manager or resource manager). Personally I use that term mostly for the front-end object of a facade implementation, because it is in the limelight as seen by the clients and delegates all the work to the hidden objects E.g. the resource manager is the public interface in front of a resource cache, resource directory, and resource loader.
Systems w.r.t. ECS means software that handles ECS component data and runs the necessary processes on the data. It is often chosen as an opposite to the distributed component management when the components are strongly coupled to the entities. That is IMHO a different definition as the one given above, so that the same term seems me to be used for different things, and looking at the context is necessary to understand.
With the above being my understanding of things, let's talk a bit about your questions.
17 hours ago, Sunny Kumar said:
I want to write a manager that generates obstacles at, say, fixed gaps and when the player reaches the middle of the screen.
BTW: Here the term "manager" is hard to be interpreted. What does it mean? A better name would hint at the purpose. Dependent on how obstacles are implemented, does it spawn game objects, or is it a procedural map generator, or ...?
17 hours ago, Sunny Kumar said:
1) Where should this manager be placed in the game loop?
It needs access to position and velocity. It makes no sense to use values that are not validated, i.e. values that may still be altered due to collision correction or so. Hence it need to be placed behind "3) Transform Update" if I understand your loop correctly. Should it be placed necessarily before "4) Render System"? Well, that again depends on how the obstacles are implemented. If they are game objects, then no (although I would place it before rendering anyway, just because it counts to the logic part of the game loop). If so, you may want to read the thread Question on organization of draw loop where I explain my approach a bit deeper. But if the obstacles are just static objects in a generated map, then putting the task before rendering allows the obstacles to occur already just after creation.
17 hours ago, Sunny Kumar said:
2) Should it even be a manager? Can such logic lie in systems?
A game loop should IMO be there to execute systems in the general meaning of the term. That may or may not be a system in the ECS meaning. With respect to the thread I've cited above, any system is allowed to have one or even more GameLoop::Task objects bound to the game loop.
Again, "manager" is somewhat an empty phrase. Please chose another name or, at least, prepend it with something meaningful. However, whether it could be "a manager" or lie in a (ECS like) system depends on how an obstacle is implemented (I know I repeat myself).
17 hours ago, Sunny Kumar said:
3) Extending upon 2, what really are Systems supposed to handle?
See the discussion above.