Dual quaternions haven’t really taken over. While there’s no universal way that people end up handling rigid body transforms, SO(3) + R3 for rigid body transforms are the norm in robotics.
Some robotics orgs choose a single representation for SO(3) — usually quaternions or matrices — and use it everywhere. Note that quaternions are more space efficient and easier to normalize, but require 2x more operations to rotate a vector [1]. So you might see a quaternion shop use matrices in a hot loop for transforming 3D points. And a matrix shop might use quaternions in a hot loop for composing many transformations. Usually you have many fewer rigid body links than points in an e.g. pointcloud so it is performance favorable to use matrices.
A final comment: Most users in a codebase should interact with rotations through a rotation library like Sophus or Manif. That library should implement left/right lerp, splines, “rotate a vector” and “compose a transformation”. There is basically never a need for a developer to know what rotation representation is being used to compute the rotation.
If such a library is correctly implemented, you can even use Euler Angles as the underlying representation and never experience gimbal lock.
[1] https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotati...
Quaternions are still important for building intuition for dual quaternions.