Something like PlantInternalAgeEvent, and include saplings, cave/twisting/weeping vines, cactus, sugar cane, where the final internal age isn't when the plant is ready to harvest (like crops would) but where the internal age just tracks when the next block will be spread.

Yep, cactus was the example I was specifically concerned with (although I'm not sure I agree that they should be a spread event, they're kind of different).

What event do you suggest the new event should be?

It would actually break some plugins now that I think about it.

Cactus and sugar cane use the same system of growth as saplings (they have 15 invisible states that slowly tick up over time), so presumably they, along with a few other plants that use that system would also be added to BlockGrowEvent. The issue is that whenever cactus or sugar cane grows up and spreads (adds another block above the existing top block), that also sends a BlockGrowEvent, so plugins that check the material of BlockGrowEvent#getNewState() for cactus or sugar cane, in order to see if it grew an extra block of sugar cane, would also be invoked in those 15 growth stages, which would break that plugin.

Cactus and sugar cane spreading up should use BlockSpreadEvent like twisting vines and kelp do, but since it's way way way too late to change that (13 year precedent), making a new event for those invisible growth stages would be the only way to do that. 

Seems reasonable, I guess we just need to be careful about not breaking any 13 year assumptions. Can you think of any issues with existing plugins?

From the potatoes blockstate file

{
  "variants": {
    "age=0": {
      "model": "minecraft:block/potatoes_stage0"
    },
    "age=1": {
      "model": "minecraft:block/potatoes_stage0"
    },
    "age=2": {
      "model": "minecraft:block/potatoes_stage1"
    },
    "age=3": {
      "model": "minecraft:block/potatoes_stage1"
    },
    "age=4": {
      "model": "minecraft:block/potatoes_stage2"
    },
    "age=5": {
      "model": "minecraft:block/potatoes_stage2"
    },
    "age=6": {
      "model": "minecraft:block/potatoes_stage2"
    },
    "age=7": {
      "model": "minecraft:block/potatoes_stage3"
    }
  }
} 

The crop ages don't actually change visually for most of the ages, but that still triggers the event. I think that that should apply to saplings too.

When bonemeal is used to increase a sapling's stage from 0->1, it does send a BlockFertilizeEvent, despite not having any visual changes. I'd think that BlockFertilizeEvent and BlockGrowEvent should both be consistent with what triggers them.

The only difference between saplings and crops is that saplings don't have a visual change, the growth is otherwise exactly the same. If you use a resource pack to retexture the two sapling stages, then there is a visual difference that can be exploited. 

Use case is to be able to control tree growth more precisely. 

Also what's the use case?

Even when BlockGrowEvent was added in 2012 it wasn't called for such age changes (see, eg, BlockCactus in commit 7792156fb25d25103d4a5e8ccfd563ff1707560d).

I'm not sure changing the way the event has worked for 13 years is necessarily a bug and it should perhaps be a separate event given nothing is actually growing (as noted in your final point).