I can't speak for the "spam companies and projects", but as far as we're concerned:

I'm not going to emphatically say "no" because who knows, maybe in the future we'll have some application where it makes sense but we currently do not. We have released and sold two inscription collections (that both put data in witness data). In both of those cases, it's not clear to me that having the data in OP_RETURNs would have been better. The main reason we put the data in witness data was for compatibility with the ordinals protocol. Our collectors want to be able to manage, store, and trade our collection in wallets they're already using -- and there are several ordinals-specific wallets out there, and any wallet with coin control could technically be used. You could add opreturns to ordinals, but it would be weird. imo, having inscription data in the input instead of the output makes the protocol cleaner and easier to implement.

So for our collections, compatibility is a bigger concern than something like the witness discount. High-value inscriptions are actually reasonably price-insensitive when we're talking about a 4x cost premium. We did a LOT of work on Quantum Cats to bring the cost down, but that was by a factor of about 100, not 4.

Outside of digital collectables, we've done a lot of work with OP_RETURNs holding data commitments for multi-transaction protocols using OP_CAT or other covenants. In those cases, usually we're putting one or two merkle roots and maybe a little metadata tag in an opreturn. So we actually haven't felt any real pain with the 80-byte limit. We actually run into consensus limits more often than we run into the OP_RETURN limit.

In general, if we did want to stick a bunch of data into an opreturn it would probably be something where:

Nothing currently fits that bill, so I don't think so, but you never know. Maybe some of the people mad about this have a fun idea they can share.