Appendix B:

    The primary problem with the "X-" convention is that unstandardized
   parameters have a tendency to leak into the protected space of
   standardized parameters, thus introducing the need for migration from
   the "X-" name to a standardized name.  Migration, in turn, introduces
   interoperability issues (and sometimes security issues) because older
   implementations will support only the "X-" name and newer
   implementations might support only the standardized name.  To
   preserve interoperability, newer implementations simply support the
   "X-" name forever, which means that the unstandardized name has
   become a de facto standard (thus obviating the need for segregation
   of the name space into standardized and unstandardized areas in the
   first place).

Most of your examples are covered under the "exception 1" clause, also in Appendix B:

   In some situations, segregating the parameter name space used in a
   given application protocol can be justified:

   1.  When it is extremely unlikely that some parameters will ever be
       standardized...
   2.  When parameter names might have significant meaning...
   3.  When parameter names need to be very short (e.g., as in [RFC5646]
       for language tags)...

They aren't complaining about custom http headers it's just the practise of using "X-" on front of the names.