I think the needs are sufficiently different that __trunc__ still has value as its own thing, and it's a natural counterpart to __floor__ and __ceil__ (out of all the directed rounding modes, rounding towards zero probably turns up more often than rounding towards +inf or -inf).

__int__ has the disadvantage that it must return an int, so it's not useful for other Python-based numeric systems with their own rational number / integer pairing. For example, with gmpy2, truncating an mpq instance returns an mpz instance, which is what I'd expect and want - if I'm working with huge values then it would be annoying for math.trunc to do the inefficient thing and return a plain int.

>>> from gmpy2 import mpq
>>> math.trunc(mpq(22, 7))
mpz(3)

SymPy behaves similarly:

>>> from sympy import Rational
>>> type(math.trunc(Rational(22, 7)))
<class 'sympy.core.numbers.Integer'>

On the other side, there are conversions to integer that it doesn't make sense to think of as truncation. It would be odd for a UUID to be a valid input to math.trunc, for example:

>>> int(uuid.uuid4())
43341414945793370480422623795805641537