Rasterization is based on the idea of projecting various primitives (e.g. triangles, line segments, points, quads, maybe even some curved surfaces like bezier patches) on the screen and then rasterizing those in 2D (the rasterization is the discretisation step of the otherwise continuous primitive). For a certain class of primitives (e.g. triangles) a perspective or an orthographic projection is cheap to compute, as is the subsequent rasterization step (additionally there is specialized hardware for that in GPUs), which explains the popularity of rasterization in the early days of real-time computer graphics. Note that ray-tracing is quite old too however, as Appel's paper dates back to 1968, albeit the idea can be traced to long before that.
This projection and rasterization step already impose some constraints such as the admissible camera model (although with much effort those may be relaxed somewhat). In contrast in ray-tracing one can pick an arbitrary camera model, with potentially a curved film and a whole sequence of lenses (a camera may even be a sphere or a mesh). Also the aperture can be modeled trivially in ray-tracing, achieving effects such as depth of field with ease, which is not the case for rasterization (even though some hacks may be employed). Furthermore, ray-tracing can work rather naturally with acceleration structures such as bvh and kd-trees, while this is not as natural for rasterization (albeit feasible in some sense).
Additionally, the class of primitives that can be intersected with a ray is much larger than the class of primitives that can be projected easily on the film (e.g. fractals can be ray-marched against, as well as other implicit surfaces). Furthermore, volumes can be marched through with a ray, achieving realistic participating media effects, which is much harder to do with rasterization. Following this, refraction and transparency are trivial in ray-tracing, while quite problematic (and even expensive) with rasterization.
The restrictions listed above are by no means complete, and those were only concerning what one would consider primary rays/direct visibility effects (somewhat arguable what lens systems, volumetric, transparency, and refraction effects should be classified as however).
When we get to lighting, the restrictions are even more severe, as most of real-time rasterized computer graphics rely on what's known as the Utah approximation (see Section 3). The Utah approximation considers only direct illumination, and ignores indirect illumination (global illumination) effects. The direct illumination considered is rather limited, in the sense that occlusion of light sources is ignored (i.e. no shadows), and the considered light sources are typically Dirac delta lights (those are non-physical) which allow avoiding integration (i.e. point light, directional light, spot light). Various hacks need to be used to put back in some approximations of the removed effects: e.g. shadow maps, ambient occlusion, ambient term, radiance probes, etc. In ray-tracing all of those effects arise rather naturally. This is not surprising, as ray-tracing is used in the modelling of geometric optics: how light is transported in the real world (albeit with some assumptions that do not hold in the real world).
In conclusion, you can see ray-tracing as a generalization of rasterized 3d graphics, where the latter is used because of efficiency considerations (although it is less efficient for some effects).
That is to say, if the hardware was more powerful, I wouldn't see a reason for using projection-based rasterized graphics over ray-tracing. Unfortunately, hardware patents belonging to tech giants lock out potential competitors, which I assume leads to a slower rate of improvement of hardware. Even worse, tech giants have been able to get patents over basic mathematics that clearly does not "belong" to them (e.g. Image generation using low-discrepancy sequences).