I didn't/don't suggest that it was Linus' idea to force people to use SELinux. Rather, I think if you review the posts at the time, the general feeling was "SELinux can do anything, and it does it right: if you're trying to implement any kind of access control, do it within SELinux because nothing else is good enough." and so for many years, until SMACK was merged, SELinux was the only real LSM user. Upon noticing this problem self-created by the kernel developers, the idea was then floated to just remove LSM because only SELinux used it, and if your access control system couldn't be implemented within SELinux it wasn't worth anyone's time, and so wouldn't be added to LSM (the self-perpetuating cycle).
Unsurprisingly, this kind of security lock-in happened to coincide with several interests.
Regarding "arbitrary security" -- I listed some things previously that don't compose a complete security model, and yet they each serve a specific and useful purpose. I think (and I'll explain in more detail on Monday) that the entire framing of discussions around "formal security models" is bogus. Far too much time is being spent on access control, when the kernel itself is like swiss cheese, security-wise. So while everyone complains about pathname-based security and AppArmor while tossing more eggs into the SELinux basket, attackers are simply cutting the bottom out of the basket.
At some point, in general, attention needs to be diverted away from access control; security != access control. Unless your name is Arjan or Ingo and you're copying features of ours, it's impossible to get anything security-related that isn't access control added to the kernel, and in fact it doesn't even seem as if anyone's interested in adding such things (or they've been dissuaded in some way). The thread in the article is a good example of why we'll always stay out of tree. If we had to fight with the kernel developers over features that they later 'reinvented', we'd have never gotten anything done and would have quit years ago.
If your "formal security model" can be remotely disabled by a public off-by-one exploit in SCTP, who's really the one with their head in the sand?