It should perhaps be pointed out that months_between (as defined by Oracle) may not be suitable for all situations.

The best, most natural use is when both arguments, of DATE data type, are truncated to the beginning of the month - values like DATE '2024-08-01' or equivalently TO_DATE('2024-08-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss').

In other situations (for more general dates), results in some special cases are definitely "wrong" in that they defy any kind of reasonable understanding. For a simple example: the value of "months between" 2023-03-30 and 2023-02-28 is 1.0645...; but if we change the first argument to 2023-03-31 (so we extend the interval by one day), the result is smaller, 1.000 even. A lot of nonsensical calculations may result from this kind of behavior.

There are other, more meaningful ways to measure "months between" two dates, different from Oracle's definition. All such definitions, even those that avoid such contradictions, will still be less than perfect, for the obvious reason that "months between" general dates (not truncated to the month) is not a well-defined concept. It can't be. But definitions better than Oracle's are, indeed, available - you just need to write your own function.

Another oddity about months_between - while it does not truncate to the month, it DOES truncate to the day (!!); time-of-day components of DATE arguments are discarded before the computation is performed. One may wonder why Oracle didn't go all the way to truncating both dates to the month - and stating very clearly that the result is only an approximation, unless the input dates are already truncated to the month.

select 
  months_between ( 
    to_date ( '2024-10-01 12:34:56', 'yyyy-mm-dd hh24:mi:ss'), 
    to_date ( '2024-09-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') 
  ) same_day_diff_time, 
  months_between ( 
    to_date ( '2024-10-02 00:00:00', 'yyyy-mm-dd hh24:mi:ss'), 
    to_date ( '2024-09-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') 
  ) diff_day_same_time, 
  months_between ( 
    to_date ( '2024-10-02 12:34:45', 'yyyy-mm-dd hh24:mi:ss'), 
    to_date ( '2024-09-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') 
  ) diff_day_diff_time;

SAME_DAY_DIFF_TIME DIFF_DAY_SAME_TIME DIFF_DAY_DIFF_TIME
------------------ ------------------ ------------------
                 1         1.03225806         1.04916555

That's not strictly true. If both dates have the same day of month, the result is an integer. Meaning any time differences are ignored.
If they are different days, then the time is taken into account.

Wow! When I noticed what I reported, I must have worked with the same day of the month (or perhaps with month-ends, where the time-of-day is also truncated).

You are 100% correct, and I would argue, this makes it even worse. How does that make any sense? I would note also that this treatment of the time-of-day component is not addressed in the documentation in any way.