Selecting a low cost, compact controller/processor for a custom sensor device
I will start by saying that this looks like a better fit for a low end FPGA (like an Artix-7 or Spartan-7) rather than an MCU.  But in any case I will address which kinds of MCUs might be appropriate first.
The ADS7047 uses a SPI bus.  The datasheet says that you can achieve 3Msps with a SPI clock of 60Mhz.
https://www.ti.com/lit/gpn/ads7047


what type of SoC device would be the best to use for driving the
ADC and writing the data to transmit


For many lower end MCUs (like PIC or AVR, PIC32 or AVR32) the SPI clock is limited to 1/4th the system clock frequency.  To get a 60MHz SPI clock you would need to use a 240MHz oscillator.  But those kind of parts don't support using an internal clock at that speed.  A parallel output (rather than SPI) ADC would be better suited if you plan to use a lower end MCU.  But don't use a lower end MCU because you won't be able to process the samples anyways.
Going yet more powerful would be something like an ARM cortex M7 or A9 MCU or a Power PC MCU.  They might support SPI clocks close to 60MHz.  But servicing 3 million SPI transfers per second is going to consume A LOT (if not most) of the CPU time.
There are a few of options to work around this.

Pick a dual core part.  One core manages the ADC, the other core does other stuff.
Pick a part with an IO co-processor.  The MCP5674 has an ETPU IO processor that can be used to manage the transfers.  Also some of the freescale HCS12 processors have an XGATE coprocessor that might be used if you can find a part that is fast enough.
Pick a part that lets you manage the SPI transfers via the DMA controller.
Pick a part that is really fast (like several hundred MIPS).



what parameters or capabilities should I be looking for to achieve
the processing speeds that I am targeting (acquire, convert, write,
and transmit 2-3 million samples/data points per second)


As a starting point assume that you will need several tens of clock cycles to process each sample.  In that case you probably need something that can execute on the order of 100 million instructions per second, but if you an get something faster do it because its really easy to run out of processing power if you are not careful.  A Cortex M7, Cortex A9, or Power PC can achieve this type of processing.
If you CAN use an FPGA, that would probably be a better fit for this kind of high rate data processing.  A $35 XC7A35T Artix-7 FPGA would probably work.  There would be almost no risk of running out of processing power in this type of application.


how can I determine the bit rate required for my application
(sending one data point file every 300-500 ns)?


For the wireless (including overhead) you are looking at sending at least 50Mbps.  Most of the low-end wireless stuff is out in that case.  You would need to use 802.11g or higher to get those kind of bit rates.
But keep in mind that wireless transmissions have to share spectrum with others (which reduces the available throughput), and messages sometimes get lost due to interference.  If you need the data in real-time without much loss then wireless might not be a good option.  If you can live with some latency, but no data loss then wireless can work but you are faced with the possibility of having a large buffer at the transmitter to hold data while you correct transmission errors.
If you can, it would be better to use a hard-wired data link (fiber optic, 10/100 Ethernet, a few RS485 lines, etc).