Нет, arr выдаст указатель на arr[0][0]. А (int*)arr выдаст указатель на int который совпадает с адресом arr[0][0]. Это уже не массив а простой указатель.
Тут итерируется до N*M, потому что я знаю что там есть достаточно памяти для такой операции.
Да, это опасная вещь и да, именно за такие трюки на С и катится большинство бочек.

А вот тут ты не прав.
Во втором примере ты просто берешь указатель на переменную, потом разименовываешь его получая на выходе ту же самую переменную. Так делать действительно можно и это не UB.
А вот в первом, у тебя происходит смена типа для не взаимозаменяемых типов, причем как закодирован float в памяти зависит в первую очередь от железа, как там процессор хранит float (IEEE 754 это всего-лишь один из стандартов). То есть на разных процессорах, в разных компиляторах результат операции float f; *(int*)&f = 0; может быть разным, поэтому это действительно UB.

Бррр... Зачем ты разбиваешь тип???
Мы делаем принудительное приведение типов. (int*)arr относится к имени arr, а не к его типу. Мы плюем на исходный тип. Как только мы начали делать каст - оно уже совершенно не важно какой там был тип изначально . У нас есть переменная и мы ей назначаем новый тип. Все.
С тем же успехом можно сделать (char*)arr, (void*)arr, (struct CoolStruct*)arr - везде мы получим указатель на соответствующий тип численно равный &arr[0][0].
И да, результат такого каста можно кастовать обратно, если конечно ты знаешь куда.

Неверно. Это как раз не UB а и есть стандарт адресной арифметики.
(int*)arr + i - эквивалентен (int*)(arr + i). То есть берем реальный тип arr (а это указатель на тип int[N][M]), прибавляем к нему sizeof(int[N][M])*i и полученный адрес принудительно приводим к указателю на int. Запись по такому адресу тебе почти гарантировано даст падение. Это тоже не UB, это адресная арифметика.
А я в примере показывал ((int*)arr) + i - берем адрес, плюем на его оригинальный тип, приводим его к нужному типу, потом уже занимаемся арифметикой.

И да, это опасная вещь если не понимаешь что делаешь или просто опечатался. Но опасная и неопределенная - это два разных прилагательных, не надо их путать :)

Вообще-то, это не указатель на массив, а синтаксическая ошибка.

Сишный каст С++ компиляторы преобразуют либо в static_cast, либо в
reinterpret_cast по возможности. static_cast переменной массива в указатель не
пройдёт: они несовместимы, поэтому массив сначала приводится к указателю и
только потом идёт его reinterpret_cast.
Вот ведь навертели гады!
В принципе то оно понятно зачем и почему такие сложности. Но... с одной стороны, даже это не всегда помогает от самострела. А с другой, при попытке "все-же сделать каст, потому что я знаю что тут можно и нужно", начинаются иногда очень странные пляски с различными типами кастов и в итоге в ногу летит не пуля а целый заряд картечи.
Мне, все же, более простой подход Си нравится больше. Он прост, примитивен, но надежен и полностью предсказуем. А вот вся эта палитра плюсовых кастов... Ух! Излишне усложнено и все равно не дает гарантию от ошибок. Лучше бы вообще запретили каст делать, больше пользы было бы.

Нет. В рамках данной темы, arr это имя переменной. Это такая сущность имеющая значение только на этапе компилятора и линкера (ну еще остающаяся в дебаг сборке).
Смена типа переменной имеет смысл (и делается) только на этапе компиляции, во время работы у программы есть только адреса памяти к которым обращаются команды типа mov.
lvalue/rvalue здесь совершенно ни причем.