Determining what range of numbers are considered as equal based on a threshold

We can not compare doubles directly using == so one of the recommended methods is to use a threshold epsilon in order to determine equality based on our precision standard as defined by the threshold.
What I have been noticing is that when having 2 doubles the check usually recommended in relevant posts is if Math.abs(a - b) < epsilon which is the part that is confusing to me.
In my understanding the comparison of the diff should be taking into account the magnitude of the numbers and not using the direct diff.
Example:
Assuming the threshold is 0.000001 in the following cases where we try to establish equality with a

double a = 57.33;
double b = 57.32973229;
double c = 57.33000002;

b would be rejected since 57.33 - 57.32973229 = 0.00026771 > 0.000001 but to me it sounds quite unreasonable given the fact that this is less than 0.0004 error (0.00026771/57.33). This is even more obvious with larger and larger (or smaller and smaller) numbers.
c would be accepted since 57.33000002 - 57.33 = 0.00000002 < 0.000001

It seems quite impractical unless in very specific situations to accept as equal only c.
What am I missing/misunderstanding here?

Update:
So why isn't the recommended approach (a - b)/Max(a,b) < epsilon instead?

> In my understanding the comparison of the diff should be taking into account the magnitude of the numbers and not using the direct diff.

In one floating-point operation, the computed result is the real-number result rounded to the nearest representable value. The distances between nearby values are scaled according to the magnitude of the result (with some quantization: the steps stay a constant size throughout one binade [all the numbers represented with the same exponent] and then jump as you transition to a neighboring binade). Therefore, for one floating-point operation, there is a known bound on the error that is proportional to the magnitude of the result.

> So why isn't the recommended approach (a - b)/Max(a,b) < epsilon instead?

When a computation involves multiple operations, there may be a rounding error in each operation. That rounding error has a known bound that is proportional to the magnitude of its results. But as a computation proceeds through multiple steps, errors from previous steps may be compounded (or canceled) by various operations. So the final error is not proportional to Max(a, b) but is affected by all the magnitudes of the intermediate results as well as interactions between the errors and operations.

As an example, consider some very large number x that resulted from previous operations. It may have some error e that is large, but still proportional to x. If we subtract from x a number y that is near x in magnitude, we get a small result, a, includes that error e. And that error e is proportional to x, so it may be huge compared to a, very disproportionate compared to earlier errors.

This is part of the reason there is no general solution for accepting as equal floating-point numbers that are not equal: Just from the final results a and b alone, we cannot know how much error could have accumulated in them. Max(a, b) is insufficient. The error could be anything between zero and infinity, inclusive, and it could also be NaN. Designing a solution for a particular situation requires knowledge of the computations used to obtain the results and the input data.