I will attempt an answer at the technical parts of the question. I had the same thought about history repeating itself or writers not knowing what they were talking about when I saw the touting of multiple languages as a feature intrinsic to NEO to the exclusion of Ethereum.
The short answer is no, the lack of language support in Ethereum is not an intrinsic property of Ethereum.
Given that both NEO and Ethereum are Turing-complete, they can, as has been proven, be used to implement each other (the terms we use now were, for perhaps obvious reasons, not used in this paper); that is, even if they can't run the same programs directly, the NEO virtual machine (VM) can simulate an Ethereum virtual machine and vice versa, using the simulated machine to execute the input, with some caveats.
The caveats of the above are indirectly relevant to NEO and Ethereum. The first caveat is that the emulated speed of execution will be slower than a comparable virtual machine; measured in instructions, an Ethereum-native contract will require fewer instructions to execute (and thus cost less gas) than executing a contract emulating the NEO VM running a NEO contract. Of course, doing the latter is silly. We'd just write native code. This leads to the second caveat: not every instruction of a VM may be emulated efficiently by another VM. For example, on computers without floating point units, it is relatively computationally costly to do floating point math -- but it can still be done. Germanely, the introduction of zkSNARKS to Ethereum in Metropolis will enable something to be implemented in contracts that would have been infeasible before. Another caveat is that input/output (I/O) and peripherals available to the virtual machines is not the same -- specifically, an Ethereum VM cannot presently directly interact with the NEO VM and I expect the reverse is also true. There are other caveats that I'll skip over (e.g., memory constraints from porting), but the above are perhaps the biggest caveats.
It is possible that NEO has a larger set of fast-native operations which make it easier to support a larger number of operations efficiently, but if this is found to be useful, I'm sure someone will propose an EIP to add support for the instruction. In the meantime, if one really wanted to write in a particular language, one could also write a cross-compiler (or write a new EVM compiler and optimizer for the parsing frontend of an existing compiler) and add some additional support to handle blockchain I/O such as determining current block number and state management.
Upon some further reading, it appears as though NEO has some I/O features that are part of its VM that are not part of Ethereum's -- specifically, triggers that cause contracts to be run such as firing on a certain date or when another account reaches a particular balance). In NEO, it's a bit like interrupt-driven callbacks; in Ethereum, this can be done (without modifying the EVM) using external polling such as Ethereum Alarm Clock. Of course, this has no effect on what languages are supported or supportable.