Robur

newObject.email = oldObject.email

в 2019 и ESXXX всё еще работает.

Если вам надо сделать новый объект, в который включить нужные свойства со старого то pick из lodash (или свой велосипед):

const x={email: 'aaa', name: 'bbb'}
const y = _.pick(x, 'email') /// y={email: 'aaa'}

Если это в рамках вашей работы и у вас нет ни того кто это писал, ни сорсмапов ни исходников - то вручную ковыряясь, долго, медленно и старательно, попросив в два раза больше денег. Других вариантов для 10к строк кода особо нет. Если там один файл то можно попробовать разбить на более мелкие - наверняка один и тот же паттерн того как они были склеены. Скорее всего может немного помочь prettifier, хотя бы код сделает более читаемым синтаксически.
Только убедитесь что это всё легально :)

Примерно так как рекомендуют тут: https://webpack.js.org/guides/production/
там конфиг, скрипты, опции.

Потому что это асинхронный код. Какого еще ответа вы ждали?

И зачем при выполнении setState() делать копию массива users,

Можете и не делать, если как-то еще дадите реакту знать что стейт поменялся и надо вызывать render.

https://github.com/nolanlawson/throw-max-listeners...
это поможет сделать из предупреждения ошибку и отловить где это происходит.
Можно просто взять идею и отдебажить без этой либы, достаточно отловить момент когда слушателей становится больше 10 и посмотреть на callstack.

То как вы описали задачу - можно сделать как угодно, вам хватит просто JS и пачки div чтобы нарисовать блоки.
Библиотека для того чтобы "нарисовать блоки на экране с ограничениями и может даже найти их размеры" не нужна.

Если стоит задача разработать какую-то систему - то берете и разрабатываете в соответствии с задачей, нужным функционалом, заданными ограничениями и так далее.

JS не самый лаконичный.
Есть приемы чтобы сократить код, но это нормально если вы пилите мелкие проекты которые и проектом назвать сложно.

например
token && axios.get(...)
не делайте так.

вместо if (cook&&cook.ptq) token=cook.ptq; можно написать var token = cook && cook.ptg || null
так можно.

в целом - лучше писать более структурировано, чем более коротко.

1) есть костыли но будет только хуже. пишите свои обертки под конкретные случаи и весь шум прячьте туда
2) ничего не понятно. Если у вас условие прописано в коде - то вам не нужно ничего "прокидывать" - у вас уже и так понятно что оно выполнилось что чему равно внутри - просто пишете код исходя из этого.

Это больше академический интерес, хочу разобраться как оно работает.

Это вы сейчас в очень глубокую нору заглядываете.

Движки стараются оптимизировать по максимуму, поэтому там очень много всего накручено помимо наличия int32.
Я не удивлюсь если в вашем конкретно примере они сделают просто a=1.5 в обоих случаях и код будет идентичный до байта.
а потом эту a подставят куда надо и оптимизируют там еще что-то, например b=c+a превратится в b=c+1.5

кроме того, есть разные компиляторы - которые генерируют оптимальный код для частных случаев, или более "общий" но более медленный.

Например для каждой переменной во время работы записывается какой тип в нее приходит, если этот участок кода вызывается достаточно часто - он помечается "горячим" и затем смотрится, если у вас в "a" всегда один и тот же тип, то генерируется быстрый код для этого типа, и ставятся проверки, если вдруг придет что-то другое, то этот код выкидывается и происходит возврат к более общему.

И много чего другого, лишь бы быстрее работало.
Даже если вы прямо сейчас разберетесь во всем, то завтра запилят новую оптимизацию где-то в глубине движка и что-то будет работать уже по другому.

если описана как async то да.
Если обычная функция то она работает как обычная функция и асинхронной вы её делаете руками тем или иным способом