leveraging Add and its friends was our approach too at first. We hit a snag when we implemented complex formulas for field extensions and elliptic curves. We noticed that unless the operations are defined for all combinations of (&F, &F), (F, &F), (&F, F), (F, F), the formulas end up being very unreadable because of explosions of parenthesis and & symbols. The syntax to add all those trait bounds seemed very convoluted, specially for the (&T, &T) case where we need to ask for a type T to have implemented Add for &T. Also, for fields, all the operations only make sense when OutputType equal to F, which made the syntax also way more verbose.
We came up with this solution that in our opinion made things simple for the trait code and for the users of the trait to implement it. And formulas can be read easily.
All of the std::ops are implemented off the operations in the trait now. I wonder if changing those to core::ops would suffice to have support for no_std easier. But I'm not familiar with that.

I wouldn't suffice but it would make things simpler. Let's create an issue to migrate to core.

Regarding the complexity around Add for the different combinations, it can be complex, but rust has tools to make it easier.

We could leverage macro_rules like most libraries, including how rust implements the trait for its core types(u8, u16, etc.). Or, if we are particularly inspired, we could write a proc macro for something like #[derive(Add)] at the expense of compile time.

Despite the extra work, it's better in the long term if we ever decide to layer traits. For example, let's say we want to define a Hash2Curve trait which requires some mathematical operations on Field types. Without it having the operations on the Field trait itself, we'd have to define Hash2Curve in a way like:

pub trait Hash2Curve {
  type Field: Field + Add<Rhs = Self::Field> + ...;

  ...
}

We could not define those trait bounds on the trait, but then type inference within the compiler or specific use cases would deny the usage of those traits. This means we could leverage the .add method defined on the Field trait, but ergonomically this leaves much to be desired.