Flow Structural Conventions

Per-Flow Design

1. Fill in the bloody descriptions. You'll thank yourself when you have to maintain it in two years. Like seriously it takes two seconds, stop arguing and just do it.
2. All Pink elements should have Error handling. Screen Flow ? Throw a Screen, and display what situation could lead to this. Record-triggered Flow ? Throw an email to the APEX Email Exception receipients. Hell, better yet throw that logic into a Subflow and call it from wherever. Or send a Notification I don't care. CATCH. ERRORS.
3. Don't do DMLs or Queries in Loops. Simpler: No pink squares in loops. Salesforce now actually warns you when you're doing this, but it still bears saying. To avoid doing this, ASSIGN a single record that you want to process to a collection variable in your loop, then do the DML outside of the loop at the end of your Flow.
4. If you have the same logic happening in various places, this is where you should be considering to use Subflows. This will avoid you having to modify the same thing in 6 places. It also makes the Flows easier to read.
5. Don't exit loops based on decision checks. The Flow engine doesn't support that well and you will have issues if you ever go back to the main loop
6. Don't use non-official components without checking their limits. Yes UnofficialSF is great, and it also contains components that are not bulkified or contain bugs.

Cross-Flow Design

1. Try to pass only one Record variable or one Record collection to a single Subflow. Intiializing a lot of Record variables on run often points to you being able to split that subflow into different functions. Passing Records and a lot of configuration information as variables is fine, though.
2. Once at the point of designing subflows, try to make those reusable as much as possible - you might be able to reuse a subflow from another main flow later if you design them well.