> That is completely unsurprising, attributes suck ass for data,
  > what would XML-RPC even have used them for?

Instead of this:

  <struct>
    <member>
      <name>faultCode</name>
      <value><int>-123</int></value>
    </member>
    <member>
      <name>faultString</name>
      <value><string>some fault</string></value>
    </member>
  </struct>

It could have been:

  <struct>
    <member name="faultCode"><int>-123</int></member>
    <member name="faultString"><string>some fault</string></member>
  </struct>

or even:

  <struct>
    <int name="faultCode">-123</int>
    <string name="faultString">some fault</string>
  </struct>

--

  > An issue which, which very much unfortunate, is not exactly shocking.
  > Json would have the same if it had integers in the first place.

XDR (used in Sun RPC) was defined in the '80s and had 64-bit integers. The DEC Alpha line had been out for 5 years or so when XML-RPC was published. It's not like 64-bit integers were unusual at the time.

  > Nul is a perfectly valid UTF8 character.

NUL is not permitted in XML documents. The XML-RPC spec's explicit directive to allow NUL puts it at odds with standards-conforming XML parsers.