I never heard of all of this having happened. To my knowledge Bitcoin's scripting language was not trimmed, it was in fact extended over the years by various BIPs [1].
What's your source for these statements?
But to clarify that one bit (I think?) they're talking about -- the code is OP_RETURN. Originally it could return larger amounts of arbitrary data, which was used to effectively store external data on-chain. It was later reduced down to only allow 40 bytes, which would be enough for a hash, but not enough to store larger amounts of state.
This was what Vitalik Buterin and others were using for things like scripting and colored coins, and Vitalik cited (concerns that devs were threatening to constrain it / remove it as a major reason he started Ethereum.
---
Vitalik about OP_RETURN (wish I had link w/ more context) - https://twitter.com/vitalikbuterin/status/929808394487320577
Edit for detail: In 2010 the "worst bug in bitcoin's history" was discovered, which let anybody spend ANY output on the chain, due to an obscure feature of the bitcoin scripting system allowing the signature script to simply "return true" before the actual script is executed. This was when OP_RETURN's semantics were changed to unconditionally fail the script if ever encountered rather than the short-circuiting behavior implied by its name and present in early versions. A quick emergency audit was simultaneously done and ALL opcodes that were unused at the time and moderately complex to review were "disabled" as a precaution.
It's not clear that the developers understood at the time that they would not be able to re-enable those opcodes for existing scripts without a hard-fork. The distinguishing between soft-forks and hard-forks were still being worked out back then. So large parts of script were in fact removed, but it was done as part of an emergency bug-fix and the permanent disabling may not have even been intentional.
The disabled opcodes weren't really that important to smart contracts though, at least not without additional primitives that bitcoin never had. There are various proposals to add these features in to segwit script or the upcoming taproot extension.
The crazy thing is: bitcoin was ethereum.
The community killed scripting because it was antithetical to the thing that makes money in BTC: trust. The constant flow of n00bs coming in who got their transactions reversed by OP codes and said "BUT I THOUGHT BITCOIN TRANSACTIONS WERE IRREVERSIBLE!!?!?!!?!?!1111" was eroding trust in the ecosystem.
Really, I think the beginning of bitcoin jumping the shark was Satoshi Dice: https://www.coindesk.com/company/satoshidice.
Anyways, Bitcoin off-chain scripting won't replace Eth anymore than any other off-chain scripting system will replace Eth. If this kills Eth it will be because people don't want on-chain scripting, not because people want off-chain scripting on bitcoin (ergo, the meta problem is that on-chain scripting doesn't scale in every sense of the word scale; fees, tx speed, finality, etc).
Caveat emptor: it's entirely possible this company could work or take off. In crypto, sometimes truth is stranger than fiction.
Edit: Just to be extra clear, the problems with ethereum, to me at least, aren't actually on-chain scaling; that feels solvable. What feels unsolvable to me is two things: 1) turing completeness and 2) compilation malleability (if the compiler/machine can change but the code can't, guess what, old code's behavior becomes less predictable over time... computing systems with longevity gain minimal entropy over time).
Edit 2: The only rational way I can make sense of turing completeness and compilation malleability as features is if the ecosystem is engineering ecological behavior in, that is to say: old programs should become less valuable unless they accurately predicted the future. Maybe that's rational?