You can of course experiment with it for your own use, but here are some of the pitfalls you may encounter:
Sleep modes. There’s often a world of difference between what the specs say and what you can achieve. Many cheap modules have regulators which draw more current than you would like. Whatever development environnement you use may add a lot of overhead. Wireless connections are power hungry. Sensors may take time to come to a steady state...
Accuracy. Temperature sensors often need careful calibration. And a bad design may mean your MCU or other components will be affect the readings.
Cases. This may sound stupid, but it’s actually often difficult to find cases that are both cheap and adapted to your needs.
Also, once you factor in the board, the sensor, the battery, the case, and especially all the time you’ll spend, it probably won’t be cheaper than an off the shelf solution.
But if what you want is to learn and have fun, definitely go ahead!
The choice of the wireless technology (and then the MCU) is difficult. Wi-Fi has the advantage that it is ubiquitous, so adding a device to a Wi-Fi network is easy. It has the drawback that for sleeping devices, you often end up having to re-associate, get an IP over DHCP, establish a connection, send your data, wait for ACKs... Depending on your setup the whole wake-up-connect-read sensor-send-go back to sleep cycle could easily take a few seconds.
Don’t know the exact figures for ESP8266-based boards (and it will depend a lot on whether you use the low-level ESP-IDF or a higher level environment such as micropython), but let’s suppose it draws 50 mA average during the awake cycle, 10 uA during sleep and you have a 5 second awake time every 5 minutes, that translates to:
(295 * 0.010 + 5 * 50) / 300 = 0.84 mA average power draw.
With a 2500 mAh battery that will last for about 4 months.
If you have a bad regulator (or a bad design around that regulator), or if your sensor needs more time to “settle” after wake up, or if your MCU draws more power on average (Wi-Fi is power-hungry), then it gets even worse. And I haven’t factored in the sensor itself at all.
Better choices especially with these short intervals could be BLE or Zigbee. But guess what... there are already cheap BLE or Zigbee temperature sensors... the drawback is that you need something to connect them to. Depending on how many sensors and where they are this may be an issue or something very simple and cheap to solve.
Also, don’t underestimate the issue of accuracy. The internet is lettered with stories of temperature sensors which are affected by the heat output of the MCU they are attached to.
But again, if you want to have fun experimenting with all that, please do, you’ll learn lots of things on the way!