Let's encapsulate the functionality related to the rtc and the data you're saving.
First, let's list what I consider as "related functionality":

1. this rtcData struct
2. the process of storing the struct into the rtc mem (updateRTC())
3. the process of loading back the struct from the rtc mem (the snippet of code below the comment //Read struct from RTC memory
4. obtaining the resetCount value from the struct (included in the code of the previous point)
5. updating the struct with a new resetCount (the line that is always right before calling updateRTC(): resetCount = someNumber)

Encapsulation in C++ means putting the functionality in an object, but in such a way that using that object hides the ugly details, and simplifies the code around the line where it is being used from.

A C++ object is essentially a group of functions that share a scope of specific variables. The functions are usually referred to as either methods or member functions, and the variables in the internal scope are called member variables or just members (this is a simplification).

There are 2 types of C++ objects: class and struct. They are functionally the same, the only difference between them is the default visibility of the object's internal variables:

• In a class, any member variable or methods is by default private, so a user of the object can't access the internal variables directly (they are meant to be used privately by the class methods). To make either a member variable or method public, it must be explicitly declared as "public".
• In a struct, all member variables and methods are by default public, so a user of the object has free access to everything. To hide a variable or method, it must be explicitly declared as "private".

In this example, you're already using a struct. Because this is an example sketch, use of a struct is ok.

In C++, a struct is very much like a normal-C struct, but you can add methods to it, and that is how the functionality listed above will be encapsulated.

Given the above, the following is one possible way of encapsulating:

//definition of the object
struct RTCData //object name, usually upper CamelCase
{
  //member variables are usually marked with a slightly different notation. In our case, we prepend "_" (underscore).
  uint32_t _crc32;
  byte _data[4];  // the last byte stores the reset count

 /* Writes the struct to the rtc mem.
    Returns the value of resetCount: if rtc mem was inited, returns the value found, or if uninited returns 0.
    Called from setup()
  */
  int readFromRTC() {  // object methods, usually lower camelCase
    if (ESP.rtcUserMemoryRead(64, (uint32_t*) this, sizeof(RTCData))) {
      uint32_t crcOfData = crc32((uint8_t*) &_data[0], sizeof(_data));
      if (crcOfData != _crc32) {  // if the CRC is invalid
        return 0;  // set first test run since power on or external reset
      }
      return = _data[3];  // read the previous reset count
  }

  //Replaces updateRTC() to reflect intent
 /* Reads the struct from the rtc mem
    Takes as arg the resetCount value to use
    Returns resetCount for convenience
 */
  int writeToRTC(int resetCount) {
    _data[3] = resetCount;  // save the reset count for the next test run
    // Update CRC32 of data
    _crc32 = crc32((uint8_t*) &_data[0], sizeof(_data));
    if (resetCount == 5) {  // wipe the CRC in RTC memory when we're done with all tests
      _crc32 = 0;
    }
    // Write struct to RTC memory
    ESP.rtcUserMemoryWrite(64, (uint32_t*) this, sizeof(RTCData));

    return resetCount; //return the arg for convenience
  }
 
};

//declaration of the object
RTCData rtcData; 
int resetCount; //use of int is more efficient vs. byte in this 32bit architecture

Now, usage can be as follows:

...
/*  in setup: 
    Replaces the code below the "Read struct from RTC memory" comment
*/
    resetCount = rtcData.readFromRTC();
...

/*  in setup and loop: replaces the two lines:
    resetCount = somenum; 
    updateRTC();
*/
    resetCount = rtcData.writeToRTC(somenum);

In the above you will notice use of this. Within any class method, this is a special member variable: a pointer to the class instance you are in. So, in this case it's the memory address of the start of the global rtcData struct instance.

I can sort of follow that part, but I'd rather minimize refactoring the code into C++ as I can't read it (and can't maintain it). About twice as many people know/use C as know C++, so re-writing it into C++ makes it incomprehensible to those of us that don't do C++. An 'example' or 'demo' should be understood by the largest number of users, not just the C++ crowd.

The other refactor (several comments below) makes perfectly good sense though. I'm all for making it more readable. Working on it...

If I'm reading your code correctly, I think the definition in the struct needs to change since resetCount is now an int, so

byte _data[4];  // the last byte stores the reset count

should be something like

int _data[];  // 4 bytes for the int resetCount

with matching revisions to readFrom and writeTo

edit: dunno if that's going to work, as the crc32 looks like it's operating byte-wide

This resetCause isn't needed, the line should be removed. You are declaring it inside setup(), and using it only there, so that local declaration is enough.

You're right, I'd forgotten I moved that whole thing inside of setup(). Removed.

For whatever reason, I got exceptions if I tried to do multiple reads of ESP.getResetReason() like this:

  Serial.println(ESP.getResetReason());
  if ((ESP.getResetReason() == "External System") || (ESP.getResetReason() == "Power on")) {

I didn't try to hunt it down, as it was a very long stack dump. I've never seen a stack dump that long. That's why I read it once into a string.

I see we already have this crc32 function in crc32.cpp, the declaration is in cores/esp8266/coredecls.h. Please reuse that one to not reinvent the wheel.

It may take me a week to figure that one out, as it's not exactly clear how to use it for a newbie, nor is it listed at readthedocs. The only example I could find that used it is equally unclear (WiFiShutdown.ino). At the moment I'm trying to figure out what this is doing, quite literally symbol-by-symbol.
nv->crc = crc32(&nv->data, sizeof(nv->data));
From what I've figured out so far, that's called "function call by reference" but giving it a name doesn't magically make me understand it. I suspect that's why the person that wrote the RTCUserMemory example coded their own version of a crc32 (that's what I copied).

Done, replaced with the one linked from coredecls.h. That was less painful than I thought.

This would get replaced by the RTCData::writeToRTC() method, declared and defined within the class at the start of the sketch.

if-else bodies on their own lines, please, like so:

if (this)
  doThat();
else if(this2)
  doThat2();
else
...

Already fixed, just not committed yet. I saw the error at Travis.