...
5) There are two primary reasons to make a box a service: you need parallelism for a box that one machine cannot do, or the box is used by many other boxes and manages state. (Plz reply if you know other good reasons, my list is incomplete)
6) if you do your work right, making a library into a service and vice versa isn't a huge endeavor.
7) the reason monoliths get a bad rap is because people throw sensible abstraction layers away and get a terrible balls of yarn
...

@HalvarFlake regarding 5) Think about how the software is about to change, and enable teams to work autonomously in a state of flow allowing to change fast rather than having to ask / coordinate all the time with everyone else (see @TeamTopologies and @suksr); think about where your org needs to innovate, and where it can use commodity / utility products / services - this is going to change over time, and not necessarily only by components becoming commodities (see Wardley Mapping)

@HalvarFlake More on 5) Embrace diversity in your tech stack. Similar to the progress of technologies on your favourite Tech Radar over time, people will bring in new tech that is worth trying out, learning its pros and cons, building skills in your org, using its benefits, and finally sunsetting it one day. To do that, you need boundaries for your services where you can do something different and possibly improve.