Ask your revision control system what it thinks about that and your teammates when you submit a 500 line diff for review when a 10 liner would suffice. That's only marginally better than someone checking in a diff when their editor converted tabs to spaces or vv.

Whitespace edits are the code equivalence of wikipedia formatting changes to increase the number of articles you've worked on without actually contributing anything.

Also, if you think that is easier to read you are actually setting yourself up by being deceived by formatting because you'll be skipping bits based on assuming you know what they say. Those are hard lessons to learn but the best way to understand a new piece of code that you're reading is not to read it like a book but like a machine, with a pencil and a notepad tracing the values of the variables as you execute the code in your head (or on the paper if it gets complex). You don't need to run the whole program that way, just the sections that you feel are hard to understand.

> To be honest it actually makes code cleaner and therefore easier to read.

It does not logically follow from the code being "cleaner" that it is easier to read. Having to scan across a field of whitespace to get to the number makes it harder to read and easier to make mistakes. Having the indentation of the number be unrelated to the length of the variable name adds another aspect that makes it harder to read and easier to make mistakes.

It's also harder to edit, which makes you do fewer edits that make the code materially better.

It depends on context. For example, here is a function from a project I'm working on:

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift"   -> Ok Shift
      "ctrl"    -> Ok Ctrl
      "alt"     -> Ok Alt
      "meta"    -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x         -> Err <| "Unknown modifier: " ++ x

I find it easier to read as is rather than if I dropped the alignment:

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift" -> Ok Shift
      "ctrl" -> Ok Ctrl
      "alt" -> Ok Alt
      "meta" -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x -> Err <| "Unknown modifier: " ++ x

As developers we spend more time reading code than editing it. Optimizing for readability seems like a better goal than optimizing for edit speed. Besides, most editors have functionality to align code. When I am looking over a file, the second example looks like a jumble of words to me, while the aligned version seems easier to parse (ha).

I agree that unaligned switches/pattern matches are bad (and in fact, there is an utility for OCaml which will nicely indent your pattern matches).

I vote for harder to read (and write), except when the variables are so tightly coupled that they should probably be in an array or other structure anyway.

But ideally this is something that should be decided by each developer's personal editor config, like tab widths for indentation.