Is there anything preventing Lightning Network from passing embedded data in OP_RETURN? As long as you pay a BTC fee for all the routing node incentives and the last layer in the onion routing includes a transaction with OP_RETURN, wouldn't that allow using OP_RETURN for various applications?

I realize the current implementations don't do this, but am I missing if there's anything that prevents it fundamentally?

Thanks!

(If the issue is that the local channel at the end won't keep track of OP_RETURN on next update, couldn't the last transaction include virtually opening a channel to the original node (the person who sent it originally) that is OP_RETURN-aware and thus would keep updating it?)
Not sure if I might miss a point of your question. But to me it seems that what you suggest is conceptionally not possible.

Lightning payments work fundamentally different than Bitcoin transactions. In particular lightning payments themselfes don't have any Bitcoin script inside them. The onion format for the payment is really just an amount, a payment hash and a next hop.

The lightning nodes themselves use the data from the onion to construct htlc outputs in their respective local channels (commitment transactions) this is where Bitcoin transactions are used to fulfill the contracts needed for lightning. The sender however has no influence on the used scripts. So there is no way to squeeze in any OP_CODES