I'll take this opportunity to also answer the OP's questions.

I answered this above. Several hundred characters fewer than 1300, but the exact amount is variable and can be as low as 0 if your payment is very complex.

Most things are possible if you try hard enough, including this. But I personally think it's a bad idea. Lightning is designed for sending a specific kind of message: instructions for creating and redeeming HTLCs off-chain. You can use this system to send other kinds of messages, but most tools don't do a job well if they weren't designed for it, and lightning wasn't designed for routing general-purpose text messages. So even though it can do it, I recommend using something that was designed for that.

No. IMO they are neat as technical demos but not smart to actually use. Sending messages over the internet is a solved problem with many, many excellent implementations. If you want to know one I am currently interested in, look into briarproject.org.

Every message is "attached to" a lightning payment which adds a point of failure to each message: if your payment fails, your message fails too. If your wallet runs out of money, your messages won't send. If your recipient uses an LSP, and they are down, your message fails. If your recipient uses a phone wallet and isn't online when you send the message, your message fails. (Well...zaplocker sort of fixes this...but not all the way. And not very well. A "real" async payments spec might fix this someday though.) In my day to day payments, lightning payments fail all the time, and I often have to keep switching wallets til I find one that works. It sucks, but since it's basically the only decentralized option, we keep working to improve it.

But this would be terrible with text messaging, where there are hundreds of excellent alternative options. Also, though it depends on your threat model, for most people it's NBD if a text message they created passes through one or more centralized intermediaries, as long as the end users' client software is responsible for encrypting and decrypting the messages. For most people, a threat model that allows corporations to know who you are messaging is not so bad if that corporation doesn't know what you told them. So I am fine with recommending tools like Telegram and Signal as better alternatives to Sphinx and Juggernaut.

They suffer from the limitations of lightning's privacy model, which you can read about here. Here is a key sentence from that essay: "Some of the top nodes on the network are capable of analyzing the source and destination of 50 to 72% of payments." If lots of people used lightning for messaging, those nodes could probably identify senders and recipients 50 to 72% of the time. (Not, however, message contents.)

If your threat model is one where you feel it is important to hide message "metadata" (that is, who is messaging whom, and when), it's useful to compare that with alternatives like Signal and Telegram. On those platforms, the companies who host the servers can read your metadata, but not your message contents (assuming you use their encryption features). And they sometimes reveal your metadata to their business partners and to governments. Do you trust them? If so, use them. Do you feel like a personal target? If so, look for something better.

If you're looking to lightning as a possible replacement, consider this: a government or corporation can request information from "top nodes" just like they can request information from Telegram or Signal. But "top nodes" might not comply. If they do, that doesn't necessarily mean you're just as worse off. Telegram can give them reliable information on who you're messaging 100% of the time you use them.

If you use lightning, the best they could get is 72%, with some limitations and caveats due to the imperfection of the heuristics (read the whole analysis I linked to earlier for more details). Also, since you pick your route, you can opt not to route through top nodes, further limiting the information available to them.

But can you do better than 50 to 72%? Earlier I mentioned Briar, which relies on the tor network as a transport and encryption layer for user messages. Tor's sends all traffic through at least 3 hops and therefore assumes that at least 1/3 of nodes on the network are "honest," i.e. not run by malicious entities. These assumptions improve for tor hidden services, which pass through 6 hops and are end to end encrypted. If only 1/3 of nodes are run by dishonest people, as tor assumes, and if you select hops at random, the chance that your message will pass through 6 randomly selected dishonest nodes is very small 1/729. (3 to the 6th power is 729)

So yeah, consider using a tor hidden service for messaging if you really need to hide who you're talking to. Briar makes this easy.