It's definitively not a good practice under "normal" circumstances, as all it really does is add clutter, and so it has a negative impact on readability (generally speaking).
However, there could be other considerations, other driving forces that could lead to code with this kind of naming. For example, some tools rely on naming conventions (and some sort of reflection/introspection capability) to generate boilerplate code between two collaborating systems. It's in the spirit of the "convention over configuration" approach. The easiest thing to do there is to make the corresponding fields/properties have the same name, and it's often useful to have them unambiguously identify their parent type (or table, or whatever higher-level structure there is), so that you don't have to check all the time. And, while naming conventions vary between systems, languages and technologies, you have to come up with a unified approach here, so the end-result may not follow the best OOP practices.
This was just one example, but as you can imagine, as people come up with new tools and technologies, all kinds of real-word factors arise that may lead to these departures from "the norm".
Of course, there's always the other side of the coin, and sometimes people write code that looks like this without really having good justification for it.