Bevy is data oriented due to its ECS: roughly: which data an entity has attached to it decides which behaviours are run. Want something to have a health bar? Just attach the Health { current: 50, max: 100 } struct and it will have all associated behaviour like being able to take damage. Want to make it invincible again? Just remove the Health struct.
This is different from OOP engines, where you might need to keep an is_invincible boolean around to check against.
Usually this is done via an entity component system.
https://en.m.wikipedia.org/wiki/Data-oriented_design
The idea is that you use data structures and algorithms to make better use of CPU cache.
More performance thanks to cache locality, makes it much easier to write multithreaded gameplay code (remember, games are basically a big ol' pile of "cross-cutting concerns" [1]), as well as facilitating simulation-y code by allowing you to address game objects by arbitrary sets of properties.
---
[1]: Games often break the traditional "layers" we like to build in software architecture to enhance maintainability. That means traditionally you often get blobs of references and mutations scattered everywhere through the code. In a shooter, the visuals for a bullet need to know not only their origin and direction, but possibly the pose of any players in their path, as well as stats about the weapon, or even network latency, for a crude example.