Can you quote the part of the lightning network specification that says that a transaction performed off blockchain is the same as one that has been confirmed on blockchain? I don't remember seeing it.
You don't remember seeing it because you probably haven't read much of anything on it, judging by your use of terminology on the subject matter thus far.
If LN is _just as_ secure as the Bitcoin blockchain, why bother with the rigamarole of the blockchain at all?
You don't understand how it works, so rather than judge it based on your misunderstanding, I suggest seeking to learn instead.
All lightning network transactions are 2-of-2 multi-sig transactions. The funding transaction is 2-of-2 MuSig, all commitment transactions are 2-of-2 MuSig, and the closing txn is 2-of-2 MuSig. They're all the same. What makes it work is the bitcoin Script involved, mainly the CheckSequenceVerify OpCode that allows for hashed timelock contracts.
It starts with the 2-of-2 MuSig funding transaction. Let's say Alice and Bob want to create a channel between each other and each commit bitcoin to the channel (5 each). But, with 2-of-2 MuSig, if either party gets up and leaves and never to return, then that bitcoin is lost forever. So it wouldn't make sense to just create that transaction and leave because you'd then need to trust another party to stay involved to be able to spend that bitcoin that's apart of that multisig since each party has one of the two keys.
So at the time of creating that funding transaction, they also each create a 2-of-2 commitment transaction that spends the bitcoin that's in that original funding transaction, sign it with their key, and send it to the other person to hang on to for their signature. These are all regular normal bitcoin transactions constructed the same way that any other bitcoin transaction is constructed. There is nothing special about them. Lightning transactions (which is what these commitment transactions are) are bitcoin transactions. At any point in time, whenever one party wants to instantly spend some bitcoin as a part of this channel, they can just simply create a new commitment transaction in a similar fashion. They each create a new commitment with the new amounts for each side of the channel, sign it with their key, and send it over to the other person for their signature.
The trick here is in how they prevent the other person from spending a stale commitment transaction state. Since all these transactions are in fact valid bitcoin transactions, they can at any time be broadcast out on the the network and validated just like any other bitcoin transaction. So what prevents one party from broadcasting a transaction that is invalid? If Alice originally started with 5 bitcoin and sends Bob one bitcoin, what prevents Alice from later sending an old commitment transaction that says Alice owns 5 bitcoin again?
That's where the CheckSequenceVerify opcode comes into play with Bitcoin scripting. The commitment transaction that Bob create for Alice to sign says that Alice gets her bitcoin after a delay period that Bob specifies and before that Bob can spend that bitcoin if he has a revocation key. When a new commitment transaction is created, Alice shares with Bob her revocation key for the prior transaction. Now that Bob has the revocation key, if Alice were to ever attempt to spend this old commitment transaction, Bob can use that revocation key to instead punish Alice and take her bitcoin instead for trying to cheat.
Since these are all just regular bitcoin transactions that can be broadcast out onto the blockchain, they're secured with the same security behind that blockchain. You just don't need to involve it every time you create a new commitment transaction because the script allows for delayed enforcement.
As an analogy, it is like a court system. The court can only hear so many cases during the day, but the court is the final say in the matter. However, just because the court has limited time in the day to hear cases, doesn't mean we can't scale the enforcement of the legal system beyond what the court system can handle in a day. So we have contracts that two parties can sign between each other that can be upheld by the courts. The court doesn't need to hear every single contract that two parties ever sign between each other. The court only needs to hear when there is a dispute between those parties. If there is a dispute, then the court hears their case and determines the outcome.
Lightning is the same way. Two parties are creating legitimate bitcoin transactions between each other that has a contract using Bitcoin's Script language. You can create as many txns (or contract updates) as you'd like between parties without needing to involve the blockchain (court). But these contracts are still secure using this same blockchain (court/legal system). If there is a dispute or either party wants to exit the contract (2-of-2 MuSig), then that is when they get the blockchain (court) involved.
When you create lightning transactions, all you're doing is creating new 2-of-2 multisignature bitcoin transactions between you and another party. There is no difference between a lightning transaction and a bitcoin transaction. Same ledger, same Script language, same signature schemes, same address formats, same everything. Lightning isn't like a federated sidechain that involves completely separate functionality.
This does mean that the lightning network is an "online" network; meaning that you need to always be monitoring (or use an untrusted watchtower) to monitor for fraudulent transaction attempts. But given that you can set your own to_self_delay to be what you want it to be for the comittment transactions you create, then you can always ensure you have ample time to catch and punish transactions that attempt to cheat. This is why lightning is so secure and why there is almost never any fraudulent txns like this with lightning.
Here is a diagram to illustrate the typical lightning channel funding and commitment transactions:
Here is an example of a lightning transaction in a block explorer where you can see the OP_CSV in the witness script details to see what one looks like:
https://mempool.space/tx/51cce9ad9fe40d8eb5f044013e3e3874356e55b316c84e749a7d53fe27cfc540This right here is going to be a barrier to adoption. Way too much learning required in order to do it right. To pay with Lightning I have to "open channels" with a certain number of "nodes," whatever that means. I'm supposed to educate myself on which nodes are good or bad to associate with. How am I supposed to know that absent some trusted (centralized) source telling me? What's the outcome if I choose poorly? Could I lose my money? Could my transactions get stuck in purgatory? I'm tech-savvy enough that I'll be able to do well at it if I ever had some actual use case for learning about and paying with Lightning, but most people aren't.
I'm reminded of when there was a brief migration to the decentralized social network Mastodon after Elon Musk bought out Twitter. I saw numerous messages about how it's good for the network if everyone would find a small server to join so things don't become too centralized, but the reality is there are a couple of big ones with "Mastodon" in their domain name that gobbled up a large share of the user base because most folks can't be bothered to spend time evaluating the various alternatives when there's a perfectly fine-looking (but more centralized) option staring them in the face.
Similar story with email. At its core it is a big decentralized network where anyone in the world has the right to start up their own email server, but the reality is that most people just sign up with an account at Google or Yahoo or Microsoft and call it a day. This has downsides! If you're trying to maintain a presence outside of the big email providers it's on you to make sure you do all the right things not to get your domain flagged by them as a likely spammer where all your messages will be sent to the round file. With less centralization there would be less ability for those few big companies to push everyone else around. The reality, again, is that most people can't be bothered to concern themselves with this, and just want to get themselves an email account with the least amount of friction in the signup process.
As with most things in tech, you don't need to understand the intricacies behind it to be able to use it. Certainly in the early days everything always seems complicated to use because UI always comes last. The foundation must be set first, then good UI/UX is built on top of it. There are plenty of good wallet apps out there now that abstract away the more complex channel management stuff that comes with the lightning network and leaves the user to just simply send and receive transactions instantly. Saying that it is a barrier to adoption when the final UI/UX of a technology isn't even in its final form yet is naive. That's like saying that dial-up modems were a barrier to adoption for the internet and now look at us today.
The important thing with these technologies is that users have the option to manage things on their own if they choose to. That is the benefit that open systems provide. They allow users to "opt-out" if they so choose. There will no doubt be those apps that choose to take the easy way out which results in certain compromises to security for the sake of convenience. The fact that there are choices though is what is important.
I use a social media protocol called NOSTR which is an open protocol and therefore there are numerous client apps out there with various features to them each. This choice is so important to open systems as it allows the user to choose what's important to them.
You mention email, and I agree there too. I host my own email on my own server and always have for the last 20+ years. Things have gotten better with email as most email providers simply require DMARC (DKIM and SPF checks) to ensure it is a valid sender. So hosting your own email nowadays doesn't really result in your email getting flagged as spam any more.
