Оканчивается эпоха восьмеричных чисел с ведущим нулём в языке JavaScript

Хмм… Странно, я использовал 8-иричные константы (но не строковые, а просто в коде) в своей странице 404.
Только что проверил — в Хроме 26-м все по прежнему работает.

      for(bit=0;bit<16;bit++)
      {
        sum = ((0164624 >>> (((v1>>>bit)&7)<<1))&3)+ 
              ((0164624 >>> (((v2>>>bit)&5)<<1))&3)+//&5 because we skip middle cell
              ((0164624 >>> (((v3>>>bit)&7)<<1))&3);
          
        new_state |= ((0340 >>> ((sum<<1) | ((v2>>>(bit+1))&1)))&1)<<bit;
      }

Исторически сложилось. В *nix файловые права удобно представлять, к примеру.

Несколько раз было полезно в математикоинформатических задачах в универе. Но это от лени и нежелания писать велосипеды

Взялось как не странно для удобства человека ;)
в те далекие времена когда для программиста была НУЖНА была информация о битах
в 2чной системе работать не очень удобно(слишком длинно) 0b1000111010001
в 8ричной же — компромис между легкостью восприятия человеком и использованием обычной записи 0-7
все цыфры кодируют 3 бита двоичного числа, и запомнить 8 комбинаций достаточно легко
как результат 0b1000111010001 -> 1 000 111 101 001 (bin) -> 10751 — легко делать в голове

в те времена у машины могла быть разрядность не кратная степени 2ки, например 18бит

16ричная систем менее удобна для ЧЕЛОВЕКА ;)
но она уже привычна
и удобна там где разрядность степени 2ки
ну и 16ричное число короче по записи
для 16бит максимальное число 0xFFFF == 0177777
в общем вытеснило оно в обычной жизни

хотя вопрос скорее привычки
на PDP архетектурах было принятов работать в 8ричной системе
на интелах обычно 16ричная
а на ZX-Spectrum были люди которые использовали 10чные числа, и их это устраивало… ;)

Подозреваю, что основная причина в том, что 8 меньше десяти, а 16 больше. С практической точки зрения это означает, что для ввода восьмиричного числа достаточно стандартной цифровой клавиатуры а-ля калькулятор, а для вывода опять же стандартного цифрового устройства вывода, например газоразрядного знакового индикатора.

Подозреваю, проблема в том, что так практически никто не делает.

Исторически — из C, в который это попало из B, а в него — из BCPL (разве что префиксом восьмеричных констант была 8 — подчеркнутая 8): sundry.wikispaces.com/octal-zero-prefix и stackoverflow.com/a/11483339

Ранние версии C даже допускали восьмеричные константы 08 и 09 — www.coding-guidelines.com/cbook/cbook1_2.pdf стр 829

Еще в википедии есть примерно такое объяснение популярности восьмеричной системы, en.wikipedia.org/wiki/Octal#In_computers

Octal became widely used in computing when systems such as the PDP-8, ICL 1900 and IBM mainframes employed 12-bit, 24-bit or 36-bit words. Octal was an ideal abbreviation of binary for these machines because their word size is divisible by three (each octal digit represents three binary digits). So four, eight or twelve digits could concisely display an entire machine word. It also cut costs by allowing Nixie tubes, seven-segment displays, and calculators to be used for the operator consoles, where binary displays were too complex to use, decimal displays needed complex hardware to convert radices, and hexadecimal displays needed to display more numerals.

Префикс то ладно… Если в исходном коде такое встречается, то это одно, но зачем parseInt его интерпретирует? Например atoi() всегда по base10 работает.

Некоторые компиляторы C для микроконтроллеров поддерживают запись 0b01010101. Удобно.

Хватит уже придираться. Лично мне даже нравится, что человек разбавляет технический текст художественными элементами, и читать приятнее, и видно, что автор подходит к делу с интересом.