This question is intentionally rather open ended, and potentially opinion based, but it is intended to act as a catch-all for the questions on how to select a device for a sensor/endpoint. Any question which intends to be more specific would need to start with assumptions about all of these points.
Question: In addition to the points below, how would someone go about selecting a good device for the sensor/endpoint part of an IoT system?
There are already good questions 1, 2, 3 on how to select specific devices for a well-defined application, and questions that address some of the points below in detail.
There are a number of clear factors which will help to determine which devices are suitable for a particular application. In the end, there are likely to be many good choices, and no obvious 'best'.
Communications. A sensor will usually rely on a wireless interface, sometimes a combined power/signal wired interface might be appropriate. Depending on the application, this might be well defined, or there might be some flexability. Communication can be built-in, or a peripheral depending on how good a fit the other parameters are. Depending on the device deployment, there is a scale of roughly increasing cost/range from wired (Ethernet, serial, USB), short range (BlueTooth, WiFi and mesh variants), developed areas (SMS, LoRaWan, NB-IoT), remote (satellite). Bandwidth and latency also factor into the choice of communication protocol. Note that often the communications parameters are fairly well defined up-front before worrying about specific device selection.
Processing power. Some sensors are just taking input values and generating packets, others are doing complex signal analysis (face recognition for example). Some communication protocols need a reasonable processing power, so result in devices which have a small (but useful) amount of left-over processing power.
Device or Module Modules have the advantage of providing an off the shelf, pre-certified solution. They may also be cheap due to economy of scale. If you already need a custom PCB, a device might allow better optimisation.
Power Consumption If the sensor is battery powered, this will limit the communication choices, and also tends to suggest a device which will spend most of it's time in a deep sleep state (i.e. running a real-time embedded OS rather than Linux).
Power Source Related to consumption, but acting as a different type of constraint. Mains/battery/solar/harvesting are the obvious choices.
Security Often security can be ignored (for one off or evaluation projects). If security is important, what is the threat model? Are encryption accelerators important? Do you need a secure bootloader with the ability to prevent firmware roll-back, whilst at the same time allowing over-the-air firmware updates?
Peripherals If your sensor uses SPI, you need an SPI peripheral. If your sensor is a USB gadget, you need USB-on-the-go. For a high-end sensor, maybe you need a touch-screen display. Define the minimum set for your application. Memory sizes and external storage may also be relevant.
Production or Project There are economy of scale questions, availability, toolchain, example code, etc. issues that might affect the choice depending if this is a one-off project, a mock-up learning tool, or a full high volume production concept.
Coding Style Depending on your existing experience, migrating to a linux or mcu development environment might be a significant cost, might be necessary, or might be the reason for the project. Often you might prototype on a more powerful/flexible single-board computer, even if an optimised sensor/hub architecture would result in splitting the functionality between two devices.
Vendor There may sometimes be a specific reason to only consider devices from a specific vendor, but generally this is one of the most opinion based aspects of device selection. Free samples, good development boards etc. might be a factor here (although someone pays for this in the end).
Software Stack You may be set on using a specific software stack (maybe to integrate with a cloud provider), in which case there can be hardware requirements (RTC, TRNG), or you might just require a certain library to be available (TLS, COAP). Each RTOS will require certain features, Linux will require more (mmu specifically).
global (satellite)", they are all "global". I use satellite in "remote" areas, where I don't even have coverage to send SMS. It's a good looking question (which basically answers itself :-)