Question: Not even "formal symbols" such as `\[FormalX]` are guaranteed to always be symbolic. Their `Protected` argument is forgotten when they are used in `Block` and consorts, causing functions relying on symbolic variables to misbehave:

```
foo[n_] := Exponent[\[FormalX]^n, \[FormalX]];

foo[5]
Attributes@\[FormalX]

Table[{Attributes@\[FormalX], foo[5]}, {\[FormalX], 
  1}](*or Block[{\[FormalX]},...]*)

```

> 
> 5
> 
> 
> {Protected}
> 
> 
> {{{}, 0}}
> 
> 
> 

Why does `Block` clear `Attributes`? Is Unprotecting and changing a (system) symbol so common that it was decided that `Block` should do the `Unprotecting` unsolicitedly?

Is the only way to be sure that some symbol does not have an `OwnValue` to use `Module` or `Block`?

Answer: 
It is illustrative to compare `Block`, `Internal`InheritedBlock`, `Module`, and `With`. Both `Module` and `With` create unique versions of the variables which are not accessible from the outside (lexical scoping, and not without [its issues](https://mathematica.stackexchange.com/a/119410/52)), e.g.

```
x = 2 y^2 - 7;
With[{y = 5}, x]
Module[{y = 5}, x]

```

where both `With` and `Module` return `-7 + 2 y^2`. `With` has the added ability to bypass `Hold` attributes, which is very useful [sometimes](https://mathematica.stackexchange.com/a/569/52). Because of this, it would be difficult to use them to run arbitrary code passed in by a user. In contrast, `Block` and `Internal`InheritedBlock` allow you to temporarily augment/overwrite an existing variable, and guarantee that the changes are reset. 

A useful example of augmentation, is automatically resetting changes made to default `Options`, e.g. 

```
Internal`InheritedBlock[{Plot},
  SetOptions[Plot, PlotStyle -> {Red, Blue, Green}];
  Options[Plot, PlotStyle]
]
(* {PlotStyle -> {Red, Blue, Green}} *)

```

vs

```
Options[Plot, PlotStyle]
(* {PlotStyle -> Automatic} *)

```

which can be used to generate many plots where the options are uniform, without resorting to crafting a [unique theme](https://mathematica.stackexchange.com/a/54637/52). A more interesting example is this [graphics parser](https://mathematica.stackexchange.com/a/32719/52) which uses `Internal`InheritedBlock` to mimic a stack in tracking the state. If you want a more extensive augmentation, though, you still need to `Unprotect` the symbol. This is where `Block` comes in as quite often you do not want to just augment the behavior, but overwrite it entirely. 

This is the use case for `Plot`, `Table`, etc. where the user supplies a symbol/expression that needs to be evaluated without worrying about whether it has `*Values`. [`Internal`LocalizedBlock`](https://mathematica.stackexchange.com/q/71881/52) extends this further by localizing things like `Subscript[x, 1]` which `Block` cannot handle.

Of course all these can be merged. Consider this [answer](https://mathematica.stackexchange.com/a/33956/52) from Leonid which traces what packages auto-load another package. It uses `Module` to set up a [closure](https://en.wikipedia.org/wiki/Closure_(computer_programming)) which uses the [Villegas-Gayley pattern](https://mathematica.stackexchange.com/a/39924/52) to augment `Needs`. Here `Block` plays the important role of blocking recursive execution.
This is not an answer as to *why*, wolfram-language-design wise, but to how:

It seems `Block[{x = new}, ...code...]` effectively does the following:

```
newValue = new;
allValues = allValuesAndAttributesAssociatedWith[x];
Unprotect[x];
ClearAll[x];
x = newValue;
try {
    ...code...
} finally {
    allValuesAndAttributesAssociatedWith[x, allValues]
}

```

where the pseudo-code `finally`-block is executed no matter what happens inside `...code...`, even on `Abort` or `Throw`. 

I tried to capture the exact order of execution of all steps.

`ClearAll[x]` clears all kinds of attributes and values associated with `x`, including `Messages`, `FormatValues` etc.