Mods like Sodium are seen as far superior to Optifine these days, which is mainly still used for its features like shaders and resource pack enhancements...
Iris has long allowed for shader use within the Fabric ecosystem, so that's no longer a particular reason to use OptiFine.
As someone who still uses OptiFine (but would recommend to use Fabric/Sodium over it instead, especially in more recent versions), here are the two (or three) reasons I still use OptiFine. And these might be outdated since modern mods can move fast, but they were why I stuck to OptiFine the last time I looked into things, which wasn't terribly long ago.
1. OptiFine allows for raising or lowering the internal rendering resolution within its main shaders selection menu. Neither Sodium nor Iris allow a comparable behavior to my knowledge.
This might be a rarely used feature, but it's wonderful for dealing with aliasing, as it's effectively supersampling if you raise it above 100% (I'd even like to see the maximum value allowed raised from 200% to 400%). Amusingly, it's a better method than OptiFine's own anti-aliasing option in the video settings part of the menu, which I find to be practically broken due to the number of issues (behavioral and performance) it has.
2. Sodium does not acknowledge that OpenGL triple buffering is active. OptiFine does.
This probably isn't too important for vanilla, but if you play with shaders and v-sync, it is. Without it, severe frame rate drops to a fraction of your refresh rate, and for an extended period of time, may occur whenever you can't maintain a frame rate that matches your refresh rate. I've found enabling triple buffering (on both nVidia and AMD) work around this. But Sodium seemingly doesn't acknowledge it's active as these drops still occur. This won't be an issue on VRR-capable displays, but it will otherwise.
Those are the two big ones.
3. Less important, but I like disabling the random rotation the game does for textures. OptiFine has a setting for this. Sodium doesn't.
I have the impression there may be a separate mod within the Fabric ecosystem that might do this third one, but as it's of lesser importance compared to the first two things, I never looked into it.
Something that surprised me recently was how much of a lack of an issue this is sometimes. I was testing Distant Horizons a while back, and allocation rates were much, much higher than normal. At its extreme, I was witnessing an allocation rate that was reaching the amount allocated to the JVM (8 GB, in this example) around every second and a half or two seconds, and thus needing to clear something like 5 GB or 6 GB that often (close to 8 GB dropping to ~2 GB, give or take). Yet, there were no stutters felt or even shown at all.
So it would appear that either not all allocation is equal in how much of a performance impact it is to clear, or the new garbage collector in Java 21 (which I am using) is just that good. Maybe some combination of the two.
Normally in the vanilla game I don't see allocation rates anywhere near that high (they are this high from Distant Horizons I guess), but I'll still see stutters with the vanilla game sometimes (performance mods or not). Usually, they seem related to chunk generation/loading/rendering as opposed to garbage collection though (which does also happen, but it's definitely the main time stutters are a concern for me; it seems rare that it alone causes a stutter, at least one I notice to be disruptive). And Sodium seems to go a further extent towards addressing stutters from that particular cause, but my typical play is with OptiFine for the aforementioned reasons.
Instead, with Distant Horizons, I found I was surprisingly core count limited while it was computing the LODs, which is generally one of the last hardware aspects you need to worry about with this game (but this is a mod). In fact, that may be why the allocation rate was so high; instead of a couple of cores doing high amounts of work, it was basically all of them. When the game is burst loading chunks to a high render distance is another moment I see both high core count utilization and allocation rate.
The allocation rate itself isn't necessarily the problem. That's sometimes just a symptom of "more work is being done/more data is being computed". The problem can arise when the garbage collector can't keep up, but these days, that doesn't always seem to be as much of an issue.
There are many alternatives, like Sodium (much better performance improvements), Iris (shaders), and many other mods which replicate some feature of Optifine (a quick search reveals like a dozen different zoom mods, same for better grass, snow, etc, which may vary in their exact implementation; I even implemented these in my own mod), which IMO has simply gotten too big for a single person to update it in a reasonable amount of time (they probably have a lot of real life obligations as well by now, given they created Optifine in 2011, 13 years ago; even if they were a teen then they now would be in their mid-20s-early 30s. Back then it was also just an optimization mod with some additional settings, with more and more "extra" features added over time; the 1.6.4 version doesn't have shaders, custom models, etc, just connected textures and a few other things like zoom and better grass/snow from what I can see, all minor changes compared to implementing an entirely different rendering pipeline or all the other customization of models and stuff, and Mojang doesn't care about how their code changes may impact mods since they don't officially support them).
Iris has long allowed for shader use within the Fabric ecosystem, so that's no longer a particular reason to use OptiFine.
As someone who still uses OptiFine (but would recommend to use Fabric/Sodium over it instead, especially in more recent versions), here are the two (or three) reasons I still use OptiFine. And these might be outdated since modern mods can move fast, but they were why I stuck to OptiFine the last time I looked into things, which wasn't terribly long ago.
1. OptiFine allows for raising or lowering the internal rendering resolution within its main shaders selection menu. Neither Sodium nor Iris allow a comparable behavior to my knowledge.
This might be a rarely used feature, but it's wonderful for dealing with aliasing, as it's effectively supersampling if you raise it above 100% (I'd even like to see the maximum value allowed raised from 200% to 400%). Amusingly, it's a better method than OptiFine's own anti-aliasing option in the video settings part of the menu, which I find to be practically broken due to the number of issues (behavioral and performance) it has.
2. Sodium does not acknowledge that OpenGL triple buffering is active. OptiFine does.
This probably isn't too important for vanilla, but if you play with shaders and v-sync, it is. Without it, severe frame rate drops to a fraction of your refresh rate, and for an extended period of time, may occur whenever you can't maintain a frame rate that matches your refresh rate. I've found enabling triple buffering (on both nVidia and AMD) work around this. But Sodium seemingly doesn't acknowledge it's active as these drops still occur. This won't be an issue on VRR-capable displays, but it will otherwise.
Those are the two big ones.
3. Less important, but I like disabling the random rotation the game does for textures. OptiFine has a setting for this. Sodium doesn't.
I have the impression there may be a separate mod within the Fabric ecosystem that might do this third one, but as it's of lesser importance compared to the first two things, I never looked into it.
Something that surprised me recently was how much of a lack of an issue this is sometimes. I was testing Distant Horizons a while back, and allocation rates were much, much higher than normal. At its extreme, I was witnessing an allocation rate that was reaching the amount allocated to the JVM (8 GB, in this example) around every second and a half or two seconds, and thus needing to clear something like 5 GB or 6 GB that often (close to 8 GB dropping to ~2 GB, give or take). Yet, there were no stutters felt or even shown at all.
So it would appear that either not all allocation is equal in how much of a performance impact it is to clear, or the new garbage collector in Java 21 (which I am using) is just that good. Maybe some combination of the two.
Normally in the vanilla game I don't see allocation rates anywhere near that high (they are this high from Distant Horizons I guess), but I'll still see stutters with the vanilla game sometimes (performance mods or not). Usually, they seem related to chunk generation/loading/rendering as opposed to garbage collection though (which does also happen, but it's definitely the main time stutters are a concern for me; it seems rare that it alone causes a stutter, at least one I notice to be disruptive). And Sodium seems to go a further extent towards addressing stutters from that particular cause, but my typical play is with OptiFine for the aforementioned reasons.
Instead, with Distant Horizons, I found I was surprisingly core count limited while it was computing the LODs, which is generally one of the last hardware aspects you need to worry about with this game (but this is a mod). In fact, that may be why the allocation rate was so high; instead of a couple of cores doing high amounts of work, it was basically all of them. When the game is burst loading chunks to a high render distance is another moment I see both high core count utilization and allocation rate.
The allocation rate itself isn't necessarily the problem. That's sometimes just a symptom of "more work is being done/more data is being computed". The problem can arise when the garbage collector can't keep up, but these days, that doesn't always seem to be as much of an issue.
When arrive Optifine for 1.21 ?
There are many alternatives, like Sodium (much better performance improvements), Iris (shaders), and many other mods which replicate some feature of Optifine (a quick search reveals like a dozen different zoom mods, same for better grass, snow, etc, which may vary in their exact implementation; I even implemented these in my own mod), which IMO has simply gotten too big for a single person to update it in a reasonable amount of time (they probably have a lot of real life obligations as well by now, given they created Optifine in 2011, 13 years ago; even if they were a teen then they now would be in their mid-20s-early 30s. Back then it was also just an optimization mod with some additional settings, with more and more "extra" features added over time; the 1.6.4 version doesn't have shaders, custom models, etc, just connected textures and a few other things like zoom and better grass/snow from what I can see, all minor changes compared to implementing an entirely different rendering pipeline or all the other customization of models and stuff, and Mojang doesn't care about how their code changes may impact mods since they don't officially support them).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?