To elaborate(and just slightly correct on this point).
The problem that classic primitive raytracing has had was that it never scaled well for complex primitives since you needed to solve the equations that could have many intersection points for a ray.
A plane (and triangle) has 0 or 1 intersection point, this is quite trivial to solve.
Insert the ray equation ( x'=x0+dxt, y'=y0+dyt, z'=z0+dzt) into the plane equation ( Ax+By+Cz = D) and solve for [t] that is the intersection distance as seen from the ray origin [x0,y0,z0] in delta units.
A sphere has 0, 1 or 2 intersections.
You again insert a ray equation into a sphere equations and after solving you end up with a classic second degree equation with a square root.
A donut can have 0, 1, 2, 3 or 4 intersections.
All these are fairly trivial shapes, but you see how the code complexity goes up very quickly even here with more intersection cases to handle even for these fairly simple shapes.
Raytracing was used with triangle-meshes (with acceleration structures) in offline renderers since it still allowed for better lighting models with free-er ray sampling than normal rendering (and now RTX has put this ability in hardware for triangle soups)
Now, for something simple as a sphere and plane, raytracing is faster than raymarching.
The difference however is that since distance field raymarching only relies on a single value (the distance to the nearest surface) and SDF functions are trivially composable there really isn't any bounds on how complex shapes you can render with the technique, as long as the combination and core distance functions are at least somewhat conservatively "correct" in producing a single distance value (raymarching is can be forgiving for inaccuracies as long as they don't over-shoot).
So while raymarching isn't really super-fast, it's fast enough that most GPU's eats them up, since it can all be run in parallel without almost any data bandwidth.
(and the fact that raymarching often converges on "big" surfaces within a few iterations only needing more iteration in areas like borders that only take a small bit of the screen estate)