I made heavy use of the No Save behavior to keep things simple, but I kept running into issues. A lot of them were fixed, but I keep finding more, either bugs, edge cases, or weird quirks.
With a large and complex project, I have to ask - how do you know these are not logic issues with your project? It is difficult to rule that out, and I do think it's sometimes unfair to blame Construct for things you can't prove are definitely it's fault - especially when we frequently deal with bugs along the lines of "Construct is not handling XYZ properly!" which then turn out to be a problem with the user project or some other kind of misunderstanding instead. From my point of view the savegame feature is a heavily used feature that's been used by thousands of projects over many years, and there are currently very few known issues with it, which is usually good evidence it's actually pretty robust. One of the reasons we have our bug report guidelines is you need to follow that to prove it really is a problem with Construct, and not yet another case of a misunderstanding or project logic issue. I know that can be a pain, but it's generally the only way things ultimately get sorted out. And if you can't narrow it down, that can be a sign it's not actually a bug in Construct.
If you make your own save system, it's also likely to run in to all sorts of bugs and issues that Construct's save system has already sorted. For example saving and loading the relationships between objects is particularly tricky. Take two instances A and B, with B being a child of A. If you load A and B doesn't exist yet, you can't set up the hierarchy; if you load B and A doesn't exist yet, you can't set up the hierarchy. You have to have a phased approach where you load A excluding hierarchy, load B excluding hierarchy, then afterwards when both exist, restore the hierarchy relationships. There are dozens of awkward cases like this through the savegame system. It's entirely possible that if you try to take this on yourself and re-do all the same logic Construct already handles in the savegame feature, you'll actually end up with a more buggy and inconsistent system - another reason it's better to focus on the built-in feature.
Also, just to confirm: is the Drawing Canvas object not saved by the system?
Drawing Canvases are saved, just not the pixel data inside them - so just the number of instances, their positions, sizes etc. Saving the pixel data inside them is actually quite a tricky feature to design. Should it save a smaller lossy image format, or store it uncompressed? If lossy, then savegames degrade the quality of images, which may end up looking bad. If uncompressed, a HD image is about 8 MB, which could be solely responsible for making a savegame go from say 10KB to 8 MB; if you have cloud saves suddenly that's a big, slow save using lots of storage quota. It'll get worse very quickly if you have more Drawing Canvases. Then in some cases if you do something like procedurally generate the pixel data, it may be entirely unnecessary anyway. Drawing Canvas has other features to save the pixel data, so the idea is if you want to do that, you can opt-in and save additional data alongside the savegame.
Updating the game and loading a savestate from an old version sounds extremely iffy, especially if the loaded objects have changed for whatever reason
Construct's savegame feature is actually specifically designed to handle this gracefully. Everything internally relies on fixed IDs (called SIDs - serialization IDs) that are robust even in the face of renaming or moving things. You can rename all your object types, layouts, families, instance variables, behaviors, etc. and savegame data will be restored exactly the same. Data for deleted objects is just ignored, and newly added objects since the last savegame are not restored as there isn't any data for them. So it should in general just work. I don't recall anyone having issues with updating a project using savegames in the past few years, so from my point of view that seems to all be working. It's also another thing you have to think about if you invent your own savegame system. Will it be robust if you rename an object or a variable? Are you tracking things with fixed IDs to make it robust? It seems to me another non-obvious thing that you might get wrong if you try to make your own savegame system, and then you've invented a worse system that you are more likely to break.