In the sense that one board always belongs to only one platform, yes. E.g., the Arduino Uno board definition belongs to the Atmel AVR platform, and it wouldn’t belong to any other platform.
But a platform is ofc different to a board. A platform in PlatformIO would be more generally defined as being for a certain series / type of chips (Like platform-atmelavr for Atmel AVR chips and platform-espressif32 for ESP32 chips), containing board definitions that use these chips, a definition / list of packages needed to work with the chip and frameworks (like compilers, uploader tools, etc) and some (Python) code to build the firmware and connect it to the PlatformIO core logic.
Technically the Uno can run the Simba framework, too.
Frameworks are like a base-foundation that applications build on. A set of common functionality and libraries, available to the programmer. A framework usually abstracts away low-level hardware details and gives nice high-level abstractions / APIs.
Take Arduino for example for the Arduino Uno. When you want to set a pin to some level, high or low, the framework offers you a convenience function: digitalWrite(). Internally then, the function will do the things needed for the target hardware, in case of the Uno / ATMega328P chip that is writing to the PORTx memory-mapped hardware registers. So you don’t have to do that yourself.
Even better, since the framework defines a set of commonly available functionality, when the Arduino core is ported to other platforms, like the Espressif32 platform, an application programmer can use the same familiar APIs that already worked in the Arduino Uno case. Under the hood then, the functions will do the right thing for the ESP32 hardware. So it also has a unification purpose in some cases.
If you don’t use a framework, you have to do all the ‘dirty’ work. (Which can be extremely fun, too.)
So if we take a look on how to toggle a pin when we use ESP-IDF
that uses a different set of APIs than what we would use with Arduino
And also includes different headers, like #include "driver/gpio.h" vs #include <Arduino.h>.
Now the Arduino-ESP32 core and ESP-IDF are a special thing: The Arduino core is an extension of the other. It includes ESP-IDF as a base (via static linkage of a precompiled version), and you can actually freely call into the ESP-IDF functions in Arduino-ESP32. You can read through Using esp-idf library within the Arduino Framework (ESP32) for the technicalities. If your question was meant to only specifically ask “Why Arduino-ESP32 over ESP-IDF or vice-versa”, this thread contains a good discussion.
In general though, different frameworks offer different things, some are even meant for different languages. Like with ESP-IDF, the standard programming language would be C (although it’s also C++ compatible). If you want to use Arduino, you pretty much must use C++ if you want to do anything useful.
Different frameworks also have different philosophies or goals. One framework might e.g. be based on an RTOS (real-time operating system), so that (simulated) parallelism can be directly taken advantage of, others do not include an RTOS. Some frameworks might only help you with very basic things, others have vast supporting libraries in their repository.
Note that if you chose to use one framework, you’re mostly “locked into” their ecosystem. In an Arduino project you can’t e.g. just include headers / functionality from Simba framework or vice-versa and expected it to work (if you don’t add the framework files and do a weird frankenstein monster). Again, Arduino-ESP32 and ESP-IDF are an exception here.
So, the choice of which framework to use can also depend on what libraries you want to use in a project. If you have a cool sensor and it only has an Arduino library available, you better work in the Arduino framework too if you don’t want to start porting the driver. (Again, ESP-IDF + Arduino-ESP32 are a special case and you can build a project as ESP-IDF plus Arduino as a component to use Arduino libraries within ESP-IDF projects, see official example).