They're not distinct or mutually exclusive. It's not just one or the other in different parts of the code, but you can use both at the same time!
Also, a lot of the Anti-OOP rants that you see on the internet are from people who have unfortunately had to work on badly written OOP projects and think that OOP=inheritance (when inheritance isn't even present in OOPs formal description, and any decent OOP practitioner will tell you that a core tenet of OOP is the preference for composition over inheritance).
The purpose of OOP is to develop useful abstractions that reduce the surface area of your components to the minimum necessary, allowing million-line-of-code projects to remain maintainable as a collection of decoupled components. OOP is a 'paradigm' in that it provides a bunch of tools and hen it defines a structure using those tools.
The purpose of DOD is to analyse the flow of data that's actually required by your results, and then structure your intermediate and source data structures in a way that results in the simplest data transformations. The goal is to produce simpler software that performs well on real hardware. If using OOP, this analysis tells you how your should structure your classes. I wouldn't call DOD a 'paradigm' like OOP, it's more of a methodology, which can be applied to almost any programming paradigm.
You should apply both if you're making a large game that you want to be able to maintain, but also want good performance and simple algorithms.
Because OOP is about components and their interfaces (while hiding their implementations), you're free to do whatever you want within the implementation of a component too. Also, once an OOP component is created, it can be used by other OOP components, or can be used by procedural-programming algorithms, or functional-programming algorithms, etc...
A common trend in my recent experience is actually to merge functional-programming techniques with OOP too. Components in OOP are typically mutable (e.g. Some core OOP rules are actually defined in terms of how the component's state changes/mutates...) but functional code typically works with immutable components and pure-functions, which IMHO leads to better maintainability as the code is easier to reason about.
It's also common to use procedural programming to define the' script' of high level loops, like the rendering flow or the game update loop.
One reason for C++'s popularity in games is that it is happy to let you write in this mixture of procedural, pure functional, object oriented and data oriented paradigms.
[edit] I'd highly recommend reading Albrecht's Pitfalls of Object Oriented Programming ( https://drive.google.com/open?id=1SbmKU0Ev9UjyIpNMOQu7aEMhZBifZkw6 ), which could be interpreted as being Anti-OOP, but I personally interpret as anti-naive-OOP and a practical guide on applying DOD to existing code that already works but has been badly designed regarding performance. The design he ends up with could still have an OOP interface on top of it, but strays from the common OOP idea of associating algorithms with just a single object.