What follows is just a note of some of the things I've found helpful. Others may have very different and better ideas. I haven't attempted to answer all the questions.

1. I always use mobile first because that is what the Bootstrap, Foundation and Materialize frameworks use in SD, and one day I might choose to use one of those frameworks.
2. I prefer the simplicity of Frameworkless so that I can build without breakpoints where possible (as it often can be).
3. I consider that it is better for learning and understanding breakpoints if one always leaves the Toggle-Breakpoints setting in Default Mode. Choosing Disable All Breakpoints does apparently have some potential use for experts, but I find it less confusing to get that effect by using the Preview (eye icon) to toggle that view on and off. While in the Disable-All-Breakpoints setting, regardless of where the slider is, adjustments to styling affect only the situation left of the lowest breakpoint (assuming mobile-first is in use). Therefore choosing Disable All Breakpoints and forgetting to revert to Default Mode before making changes can result in a confusing mess. Using the Preview icon is not only safer, but also quicker.
3. I try always to give a suitable class name to each element that I style, rather than the one automatically given by the program. Having a page where, for example the containers are named just 'container-1', 'container-2' etc. is most unhelpful when one is using the Elements Tree to rearrange elements.
4. When I started using SD I assumed that Components were something for advanced users, and failed to realise that they are brilliant for even the simplest of things. I would urge everyone to get used to using them early on.
5. I have a habit of making a whole-page container for each page of a website, and for everything on the page to go within that container. That means that, if I want to make a very similar page elsewhere on the website, or even in another website, I can simply make a component of the whole-page container and use and modify that.
6. As with Components, it's worth learning early on how to use Symbols: they're brilliant.
7. As to workflows etc. my suspicion is that particular such patterns of behaviour may be more important when not using SD to build websites. SD is in my view something where one can operate in a fashion more like jazz.
8. Backing up is, of course, vitally important, but having a folder for an SD project, and making regular backups in it with different numbered prefixes or suffixes (e.g. myproj-1, myproj-2 etc.) is in my view the most useful because, if one messes up, one can revert to an earlier version of the project.

Enough of my ramblings.

Frank

Just a PS to my last post.

If one wants a container or other element to increase or reduce in size (but not in shape) according to the width of the end-viewer's browser, one can set the element's width and height using vw rather than px units. In some circumstances this sort of technique can reduce the need for breakpoints.

Frank