Why do ImmutableList.of() and friends prohibit null elements?

Summary pretty much says it all. Here's the relevant snippet of code in ImmutableList.createFromIterable():

  if (element == null) {
    throw new NullPointerException("at index " + index);
  }

I've run into this several times and can't see why a general-purpose library function should impose this limitation.

Edit 1: by "general-purpose", I'd be happy with 95% of cases. But I don't think I've written 100 calls to ImmutableList.of() yet, and have been bitten by this more than once. Maybe I'm an outlier, though. :)

Edit 2: I guess my big complaint is that this creates a "hiccup" when interacting with standard java.util collections. As you pointed out in your talk, problems with nulls in collections can show up far away from where those nulls were inserted. But if I have a long chain of code that puts nulls in a standard collection at one end and handles them properly at the other, then I'm unable to substitute a google collections class at any point along the way, because it'll immediately throw a NullPointerException.

I explained this at the 25-minute point of this video: https://youtu.be/ZeO_J2OcHYM?t=1495

Sorry for the lazy answer, but this is after all only a "why" question (arguably not appropriate to StackOverflow?).

EDIT: Here's another point I'm not sure I made clear in the video: the total (across all of the world's Java code), amount of extra code that has to be written for those null-friendly cases to use the old standbys Collections.unmodifiableList(Arrays.asList(...)) etc. is overwhelmed by the total (across all of the world's Java code) amount of extra checkArgument(!foos.contains(null)) calls everyone would need to add if our collections didn't take care of that for you. Most, by FAR, usages of a collection do not expect any nulls to be present, and really should fail fast if any are.

In general in Google Collections the developers are of the group that does not believe that nulls should be an expected general purpose parameter.