I thought I'd chime in here.
Originally, google incorporated the "Internet Calendar Standard" (ICAL -- not iCal, that's mac only), which was an open standard for calendar databases. It began when programmers wanted an alternative to Microsoft's VCAL standard (short for VISUAL CALENDAR STANDARD --a reference to their programming utilities, which natively handled these types of items if the header data was included).
While they were attempting to write something different, they ended up with something very similar, and the two originally worked well together in a one way communication mode. Some programmers got brave and programmed two-way or multi-directional modes that were edit capable from Microsoft Outlook or the other platform that was using ICAL.
The problems they dealt with were figuring out how to format data, since VCAL could use HTML (you could copy from any document you created in Office programs or use a mail merge operation to create many events) and in ICAL you had only plain text; the other problems was how to deal with recurring or repeating events, since Exchange treated them as one piece of data with a modifier that denoted how they were duplicated. Microsoft was focused on memory space, since that was costly when the programming was created, and open source was focused on expedience and portability.
Most of this HAS NOT CHANGED. Google still uses the ICAL standard as its primary guideline on how to do calendars, since it's portable and the programming will be similar across platforms. However, with more people using more powerful systems, with more than enough power to handle some visual formatting, Google has "allowed" HTML to be added in the data fields.
What they have not yet done is set up a section of the API to handle it for you. You have to build your own data handlers for dealing with HTML, and displaying it. In short: YOU HAVE TO PARSE THE HTML FOR YOURSELF.
Many visual platforms DO IN FACT have an HTML implementation. The best practice, then, is to grab just a bit of the text, and find out if there is HTML present in it, parse the HTML if you need to, then display. Another option is to find the HTML, then remove it. There are repositories on GITHUB and in SourceForge that have methods for removing the HTML from text, turning it into PLAIN TEXT.
I have experienced the same confusion, though, admittedly with different overall problems to solve. I've done it for the last 20 years. It was a lot of reading and finding the right people to augment my own capability for a particular issue, but ultimately, the interconnectivity and secure access markets have begun to work together in providing the linkup between platforms.
Early in the Google life cycle, it all had to be done with powershell and WinAMP apache, using javascript to drop information into temporary files that were then picked up by the opposite programming interface. It meant programming watchdogs (applications that checked if there were changes to files etc) into each system, then having each platform check to see if it was the start or the end of the update chain. It was daunting, and clunky, and it was leveraged over internal servers with little power to spare, but it ran.
Eventually, places that dealt with the APIs of either or both would have to buy into large sets of servers to handle the processing loads of different operations, but most of them still stayed limited to small sets. Only one or two moved on to "Bigger and Better Business" structures. Now the big ones are all hybridized, the small ones usually have a single server for internal operations, and are all cloud for their communications. That move was considerably more difficult.
