It's accurate to say that lightning makes it's own tradeoffs, but it's not accurate to say it's not Bitcoin.
Every lightning transaction is just a regular bitcoin transaction that could be posted to the chain at any time-- you just don't have to, because the scripting functionality has been used so that if a counterparty posts an earlier state you can effectively cancel it.
The switch to deferring updates unless there is a dispute gives a massive advantage to scaling (e.g. number of tx per second possible goes up the more users there are rather than being a global constant), instantaneouness of transaction irreversability (as fast as the involved parties can make a couple round trips, vs an hour for multiple confirmations), and potentially privacy (since not every update is globally broadcast). But these benefits come at a considerable cost of requiring a degree of active monitoring so if a counterparty posts an outdated state your software can respond, along with additional software complexity, etc.
For some applications the benefits are well worth the costs, for others they aren't.
To say it's not bitcoin is like saying multisignature transactions aren't bitcoin. In both cases they're ways of using the existing functionality. In both cases they require some additional software and different approaches. In both cases they use functionality built into the protocol which was intended for their purposes (payment channels being a concept originally described by Satoshi, and specifically accommodated in the transaction format). And in both cases they change the tradeoff surface somewhat.