Sometimes if you're using off the shelf libraries they have types compatible with what you are doing, but you don't want to mess with that lib's objects since you are reliant on THEIR codebase updates. That's usually the first case to extend and object via typecasting. It's one of the WORST scenarios you can end up in -- ESPECIALLY with Java -- but these days with off the shelf libraries, frameworks, and includes being all the rage, sometimes there are just large sections of codebase you don't want to be modifying, or even have permission TO modify. Sucks, huh?

That library made the object and you can't change that part of the code since it might neuter your upgrade path or screw over what other dev's working on the same project are expecting, a typecast is often the cleanest answer to override/extend the type.

Another scenario is when you are writing a library where any number of different object types could be passed, so you try to detect them. Hence the instanceof check -- it might be that type, it might be some other type you do not want to override. Sometimes doing this is equivalent to how in JavaScript you'll simply typecast 'this' or check typeof 'this' since things like Function.call and Function.apply can screw with what 'this' is. Whilst Java is to JavaScript like Ham is to Hamburger, they both have the funky half-assed object model where you often have to deal with cases like that.

I'm not a fan of Java's object implementation just because it's an overplumbed mess compared to where I learned objects (Smalltalk, Modula, Object Pascal, Ada) some decade before Java was a twinkle in Goslings eye. Same for C++ really... half-assed half-baked objects.

One case for using typecasts is when the newer/descendent object has overridden an existing method, but you want to use the parent method from outside the object itself. Then typecasting is the fastest way to deal with this since super() can only be done in the constructor and ... gah, it's been a while since I've dealt with Java, what's the internal method for accessing the parent class' methods once you've overridden? I've completely spaced what Java's version of that is, but it's something that's generally not available from outside the class/object instance. This is a common problem across ALL object based languages and typecasting is often the only way around that.

That also plays well with when you have multiple object types that have different methods but compatible data -- since you may want to use the methods of an entirely different class on that data. This is a weakness in the object model over non-object records/structs that can be dealt with via typecasting.

Another usage case is when you have a third class or routine in which the methods applied to the data is determined by said routine. An example might be a game where there are multiple similar classes data-wise (player, enemy, missile) where each has a different rendering and behavior depending on the part of the map they are on. It can be faster/cleaner to simply typecast them to the behavior you want from the bounding-test routine than it is to call the bounding routine from the objects themselves. This is particularly true when doing so may end up slower, such as when the overhead of the method call to the object being checked/drawn can be cut out of the equation when 'out of bounds' for render. It's easier to keep the render and behavior on the object itself, but to centralize the 'is it on screen and is it in these zones' to another object/handler. A single switch+typecast can save you a slew of processing time over integrating if/elseif/elseif/elseif/elseif in each and every child method. The "CORM" method -- Check Once, Run Mostly. A popular technique amongst assembly language developers when optimizing for speed -- unroll everything then compare once to call the appropriate optimized routine, instead of multiple compares "inside the loop". Works well in high level languages too!

Though I bet what you are seeing is people having come across those typecasts and copying the technique without understanding why it was done and how it doesn't apply to what they are currently doing. That's FAR too common these days as less and less people take the time to understand why things work or how to do things on their own, and just slop together their codebases via Google Search, Stack Overflow, and blind "copypasta".

Java, PHP, JavaScript, HTML, CSS, Python, we're seeing WAY too much "just copy what this joker did" and not enough questioning "hey is this even right or necessary?"