Unfortunately I cannot recall where but I definitely read it somewhere, that the use of delta time should be avoided for some reason. Is there really a scenario where controlling animation or other in-game events using delta time is bad or it was just a wierd dream of mine?
Using delta time is usually the correct solution. However the issue I believe you're thinking of is using a varying delta time in conjunction with a physics engine. In this case the time step should be fixed for the best/most consistent results.
Fix your timestep is a good resource on the matter.
Adding to @elFarto's answer, you should use a fixed timestep for all game logic. You really want AI and such in sync with physics.
You use your frame's delta time to update an accumulator to know when to step your fixed timestep.
You also apply the delta time to interpolation when drawing. A frame must be drawn just before the next fixed timestep. If you just draw the current state, you'll end up with some jitter in movement. You need to store both the "last" state (relevant bits for graphics) and compute one step ahead. You can then look at your time accumulator to see at what point you are between those two steps and draw interpolated values (positions, rotations, animation data, etc.) that represents that time. So long as your fixed timesteps aren't too far apart, you shouldn't see any glitches from the interpolated values, but it will hide any jitter.
The jitter is less pronounced the smaller the timesteps are. For simpler 2D games, you can often set your timesteps to particularly small values (such that every frame typically is 'stepped' many times before rendering). Because the values are so small, interpolation won't be necessary.