> I have not yet seen a good reason as to why that alignment is desired in the first place

Alignment is desired because it enhances readability. All good visual design incorporates elements of alignment, grouping, separation and so on.

> why not just have your editor wrap the line

We could write function calls, no matter how many arguments they have or how large the expressions, on one line. That will result in an excessive line length. Generally, you want to avoid code wider than about 100 columns.

You may find yourself working with a prescribed coding convention which imposes such a constraint.

If you rely on an editor wrapping the line in a clever way, that's good for you. But you don't now how other tools will react to the long lines. E.g. someone wanting a print out of the code may find that the lines are getting truncated.

> what would be the reason to force spaces on everyone else and make them suffer from an indentation width they don't like?

Using tabs for indentation and spaces for alignment requires extra care, and a carefully tuned editor setup which understands the semantic difference between the tabs and the spaces which follow. In any sizeable team, deviations in formatting will creep in. Enforcing it will just be a big waste of time, compared to the simplicity of banishing tabs.

People who suffer from an indentation width they don't like have a psychological problem that perhaps makes them unsuitable for this line of work. The professional developer can happily work with any indentation format and maintain it as-is.

The only halfway valid argument here is regarding people with severe visual disabilities. Everything else is whiny primadonna fluff.

Tabs are still not the right tool here; accessibility has to be solved in such a way that the visually disabled developer is able to work equally well with any code that is thrown their way, tabs or spaces. You don't get to work on nothing but code that was developed in-house with accessibility in mind. Third-party code happens.

Also, you are overlooking that indentation isn't necessarily aligned to an absolute grid of tab stops. Nested indentation can start at a misaligned position.

(let ((fun (lambda (arg)
(indented-two-spaces))))
(also-two-spaces))

The indentation within the lambda is relative to the (lambda ... form in the previous line. If we change the variable name from fun to func, the entire lambda moves to the right by one character.

(let ((func (lambda (arg)
(indented-two-spaces))))
(also-two-spaces))

"Tabs for indentation" is not a generally valid principle.

It could work if tabs actually expanded to a fixed number of spaces, rather than advancing to an aligned tab stop.

(let ((fun (lambda (arg)
[TAB](indented-by-simply-expanding-tab))))
[TAB](also-indented-by-tab with
[TAB] split arguments))

Now suppose the whole thing above is at some nesting level:

[TAB](let ((fun (lambda (arg)
[TAB] [TAB](indented-by-naive-tab))))
[TAB][TAB](also-indented-by-tab with
[TAB][TAB] split arguments))

As you can see, we need a more general mixture of tabs and spaces to have resizeable tabs such that alignment is preserved. Furthermore, tabs have to just expand to a given number of spaces (acting as a kind of variable-width "superspace"), rather than forward to the next aligned tab stop. (I don't think my editor can do this and don't know of any which can). The code will not look right except on such an editor.