Thank you for taking the time to write this, as it is a useful collection of tips that anyone here can use to improve themselves as developers. I want to add a few things to this list, then I'm going to sticky this particular topic.
1. Versioning (Iterations): It cannot be overstated how important a beta branch is in game development. Think of it like a gap between your unstable branch and stable branch. Once you have an unstable branch (also called a developer branch) that is clear of any gross game-breaking bugs, but still needs more refined bug-testing, push it to the beta branch. If this is a non-jam game, you'd give your testers (whether it be internal QA or an open beta or whatever) who will test it beyond what you're capable of doing (you're going to be blind to your bugs eventually). Once the beta branch is tested, approved, and ready for the general public, push it to the main/public/stable branch. For contests, your idea is just fine.
2. Playtesting: You go over a lot of amazing points here, but I want to touch on something that a lot of new developers forget about... "halo testing". Whenever you fix a bug, you want to test the areas affected by that fix (like a halo expanding outward). So if you fix a map event, test the stuff the player can do leading up to and after it, as well as anything that uses the same switches or variables. This can considerably increase the length of test time, but it can fix issues that would break your game during runtime that you hadn't even considered.
3. Time Management: I remember that you brought this up on another game's page, and while I agree with it, organization (project management) is just as, if not even more important. Not everyone thinks like you do (using downtime to develop), and not every person can. We're all wired differently, and it's not fair to assume that a person can use bathroom breaks (like mentioned in your post) to brainstorm their game. For example, I'm a lot like you (we used to make jokes that my best ideas came to me while I was on the toilet), but my wife Teal is not. However, everyone can benefit from real project management skills. You don't need to be a SCRUMM master, but you do need to have a good grasp of the concept.
4. Typos: You sum it all up with this line "Another trick is to read out loud when you playtest or re-read your text." This is something I've been using forever with my writing. It works. Every time that I haven't done this, I've made ridiculous errors. Every time that I have done this, I've been as error free as a human can be.
5. Volume Control: This is different for every developer and every player. We had to manually adjust the volume for every game that Teal played before starting the stream or coming back from BRB. You are correct in your advice, and I try to advise defaulting to 60% for RM games' volume, but I wanted to add that streamers should always test their volume beforehand.
6. Points of No Return: I couldn't agree more. You should show it and have it be said in character, though, if at all possible.
7. Pigeonholing the Player: I saw this firsthand in this jam. Teal has a very different way of playing than Hawk, for example, and problems that stumped her Hawk breezed through. And visa-versa. In almost all cases it was because the developer had only allowed for a single solution. Options are key to a good UX.
8. Colorblindness and Deafness Accessibility: Yes. Yes! YES! 100% this! (ahem... moving on...)
(I'm skipping the next several because I essentially agree with what you're saying and can't add much without repeating you.)
9. Realism vs Comfort: My advice is to always err heavily on the side of comfort (most if not all games created by AAA studios follow this metric). People don't play games to immerse themselves in real life, they play them to escape it. Even some of the most realistic physics-based VR games I play (VR usually has to have a high element of realism) allow for more than enough comfort at the sacrifice of realism. So... yeah... comfort wins over realism.
10. Taking Criticism to Heart: Most of my online career with Teal is built on giving feedback, but you hit the high points here. I want to expand on a few things that I hope will help developers in the future. (1) Any meaningful criticism is going to be levied on your project and not you, so don't take criticism of your game as an attack on you, your life, your time, or anything else. It's not about you, it's about your game. (2) Never defend or retort against criticism. Only respond when clarification is needed on either end. If a player sees something in your game, you are far better off trying to understand why they see it that way instead of explaining why it was created that way (unless they ask, of course). (3) The proper answer to any and all criticism is "Thank you for the feedback." If you feel your hackles raise at a piece of criticism, just copy and paste that line, and then walk away. Trust me, you don't want to engage when you're upset, and you definitely don't want to argue. If you think of a clarification point later, come back and ask. (4) Not all feedback can be used, but all feedback can give you insight. If someone trashes your project in a review, you only need to step back and ask yourself "Why?" Unless it's an obvious troll, the answer is not "They're wrong." (5) Never attack. Never. You will get a bad reputation. Streamers, Let's Players, and Game Critics talk behind the scenes. You don't want to get a reputation as "that dev."
Good stuff all around, Al. You've given a lot of great feedback in this game jam. Thanks for participating! :D