If we are talking traversal, forcing the player to engage in new mechanics naturally is the best way of going about it. Some games do it so well you wouldn't even know you just played through a tutorial.
In the JRPG genre, and if talking about battles specifically, tutorials should be straight and to the point. Gradually enabling new abilities and forcing the player to use the newest one every turn will teach them all the basics in a succinct manner. I've played JRPGs with a lot of flavor that unfortunately try to carry that flavor into even the tutorial. The result is that the flavor text drowns out the explanations, or worse, has the player lose sight or interest in what you are trying to teach. I would advice to avoid that. Naturally, you still can have the tutorial battle be a battle that takes place as part of your story, like the hero's first encounter with a wild animal for example.
If you're curious how I handle my game's tutorial, feel free to download it and see within the first three minutes.
There's two kind tutorial I prefer, the one that seamlessly integrated into game flow story (like the one in skyrim) and the one can be accessed anytime on starting town/menu. I don't like when the tutorial become intrusion when I plays, even it had choice to skip it.
Feels like there was a topic like this not too long ago. I used to be way against forced tutorials, but I've come to accept that not forcing tutorials and not hand-holding players early on will cause a portion of them to just ignore instructions altogether and then get stuck on your mechanics. I used to allow players to figure things out for themselves before, but I feel like it's just not an effective way to get people into your game. I used to have optional guides people could look up on from the menu, but in my experience, hardly anybody bothered checking those out and it just seemed like a waste of development time making them.
I don't mind forced tutorials, as long as they're made short and to the point and introduce mechanics as they become relevant to me as the player, and it's what I'll be going with from now on.
I keep it short, sweet and to the point for tutorials... and maybe include them into the actual narrative of the game whenever I can. I also give the player the courtesy of choosing if they want to do the tutorial or if they want to do it on their own, just in case.
I would also have it so you have tutorials for new, relevant things as opposed to front-loading everything on you at the start of the game.
Fun fact: you don't even need text to convey tutorials if you do it correctly. Just put them in a situation where they can't progress without using The Fun New Thing and throw similar obstacles at them in the future and see how they deal with it.
For my current project, I've kept the main controls intuitive.
So the player can figure things out on their own. If they want to learn all the controls, the tutorial section is right there in the menu.
They can't miss it.
Edit: If you have complex mechanics, that you want the player to try out a few times after each small segment. Then you can take them to a different map when they click tutorial. And have them go through an extensive lesson on the mechanics or systems in your game (as they try them out individually).
I decided in my project that immediately after the opening cutscene the game will introduce mechanics alongside story building. This starts with a practice battle which ends up being a trap set by an agent of false destiny who you obviously can't win against, this is taken as weakness so he sets off the failsafe to cut things short thereby introducing timed scenarios as you try to get out before the implosion sequence goes off. From there you have to go to the main fortification, the fourth member of your party is waiting after having needed a bit more time than expected for a routine errand which essentially saved his ass from being in the building when it blew up. After checking with the lordship you're called into the guest room by another associate who also required extra time (see a pattern here?) You get some cash for your troubles, then it's off to the harbor up the road. A party member suggests that you do some investigating, you have to check in with everyone in the settlement to move the story along (while you also learn about the services that you can receive while in town). Once you investigate to satisfaction the wild beasts start to move, you get jumped by a random assortment of either bats, slimes or both. After that (and following the opening credits) you're turned loose to explore and complete your quest as you wish.
Generally speaking, there are a few strategies I employ.
1. I explain nothing to the player that isn't easy to intuit. Your controls, for example. I don't explain these unless my controls are basically different than every other game on the market. If my Y button jumps instead of B, I note it for the player. If my X button is "interact" instead of A, I note it for the player. Likewise, any game mechanic a player can figure out just by experiencing it a couple times, I don't bother explaining at all. Things like the "type advantages" in Pokemon fall under this heading. Hit a Pokemon enough times with the incorrect type of move and the "It's Not Very Effective..." message gets the point across. I feel zero need to explain these types of things to the player. Though, I may have a "type chart" somewhere in the game world for players who explore.
2. I try to keep the tutorials as "Organic" as possible. If the player talks to an NPC, they are given a small piece of advice that pertains to the game world. For example: "Strong monsters get angry when you hit them with things they would usually be weak to." This is a hint at the "Revenge" mechanic in my game that boss monsters and a few overworld creatures use. Early on, being hit with "Revenge" will mess up your party, but probably not result in a Full Party Wipe. So, if you hit the Plant Boss with Fire, it gives a message, "X Seeks Revenge!" before hitting your party or a single party member with something pretty bad. But, if you hit the Plant Boss with an Ice Attack, no message, and slightly reduced damage against them than the Fire Attack landed. Even if the player doesn't quite understand what the NPC told them, they might remember it once a Boss uses it on them. The mechanic itself is designed to get players remembering ALL weaknesses, rather than a few (or, to at least experiment in combat before boss encounters to discover the alternate and less obvious weaknesses).
3. Complicated mechanics are taught in small bursts. Damage in my game is a complicated affair to have to learn and keep in mind. The general thought goal is that the player should be keeping several sets of gear around to tackle new challenges and swapping equipment (other than weapons) to deal with it. Damage is dealt based on:
A. Stat the attack uses.
B. Element the attack is.
C. Strengths/Weaknesses of the Target Stats.
An enemy can be weak to Water Damage, but also have a high Magic Defense stat (which means you'd need weapons that deal Water Damage instead of Magic). An enemy can have high Defense stat, but also a low Agility stat, which means you can kill it quickly if you're using skills that target Agility as the defensive stat (basically, fast characters can kill them).
This is a complicated system to teach and look how large this block is already with just simple examples. Likewise, each monster is basically immune to every single state except for a couple.
The Tutorial is given to the player in small pieces in order to teach them the individual parts of it and let them build upon what they've learned. "If you wear heavy armor, then the wolves around here with surround you quickly and kill you! You need to be quick on your feet to avoid that fate!" an NPC will tell the players. This is a cue to swap out any armor the player is using in order to maximize their speed stats or even agility stats. This initial lesson exists just to teach the player that they need to swap out armor and that it doesn't matter what their Defense stat says, they can still get wrecked by enemies faster than they are. The next lesson is on "archetypes" of enemies. Which enemies will generally have which types of stat spreads and which elemental weaknesses. "Armored" enemies will tend more towards Piercing Damage as a weakness as well as have very low Agility stats to defend with, so attacks that deal damage with Speed will win (these two things are taught separately, since you won't have anyone who can deal damage via the Speed stat so early). Then, enemies that are generally very quick (or look very quick, mostly Beast type creatures) are usually weak to anything using the Magic stat to attack with. This is taught a little bit by a different NPC talking about the same wolves. "If Wolves give you problems, you should try burning them. They run away if they're burning!". If the player tries out Fire on the Wolves, they will take a good chunk of damage from the hit, and if they happen to get the state "Burn", their next action is "Escape".
So, I teach this very large and complicated system in small chunks. Each piece in time. Each enemy type as it comes up. Each damage type and stat type as the player has access and it becomes necessary to learn it.
4. I don't toss up boxes at the player to tell them the specifics of a game mechanic. "If this meter fills, use this attack, and it will deal a ton of damage!" is not something I prefer to do. It sort of kills immersion and usually doesn't allow the player to experiment.
5. I allow the player to experiment. Most tutorials will slam the information into you and force you to do whatever they want you to do in order to progress the fight. I don't like doing this at all, as a tutorial. I hate it as a player as well. I prefer to give the player the information, then toss them into an area where that information is valuable and useful. Likewise, the information given isn't useful in every single situation either and the player needs to play around with it some. I don't give the player a tutorial on how the Crafting System works and then give them enough crafting materials to make the few items I want them to make in order to show them how crafting works. Oh no, I dump dozens upon dozens of crafting materials on the player so that they can play around with the system I just taught them and maybe make better equipment than I showed them how to make. I give the players the resources to play around with something they just learned. You don't get thrown some Materia and then told, "Hey, to really do anything with this system, you need to gain 300 AP to level it up". No, you get given like 12 Materia, some of it can link together, the initial level up of it might cost you like 30 AP so you can see how that works, and then I give you more Materia as you clear each new area and the new Materia would have different effects to play around with.
So, if I tell a player "Plants are weak to Fire", I give them a few plants to fight... and then toss Bugs at them too. I also toss some Beasts at them as well. The player has learned that "enemies have elemental weaknesses", and now I'm letting them experiment to see which creatures are weak to what things. Maybe, just to throw a curve ball at them, I also throw a single enemy made of Metal at them too, so they have to figure out how to kill a metal creature as well.
For exploration, I just put the player in a safe area where they can practice moving and pressing buttons. For special field abilities (like jumping or shooting projectiles) I do something similar where I give the player an area with no combat and a very simple "puzzle" to try out their new ability. Generally I try to show simple examples first then introduce complexity later. If I give the player a jump ability first, then a projectile, then I would give them a simple obstacle to jump over before I make them jump multiple times in a room. When I introduce the projectile, I'll make them use it by itself first before giving the player something that requires both abilities.
For combat, I do something similar where I make a relatively harmless fight that lets the player try out different options without getting overwhelmed. I think it's fine to use a forceful approach and require the player to perform certain actions to proceed. It's better to be up front and just tell the player what they need to do - you can use "natural" dialogue if you want, but the player needs to know what's being asked of them. I recommend avoiding vague hints or long textboxes. A simple "The enemy is charging up a big attack. Block it!" does wonders.
I'm also in the camp that thinks players can't be trusted. I have been in way too many threads where players don't understand mechanics more complicated than mashing attack because they 1. don't experiment, 2. don't read, 3. mashed buttons to get through the one time something was required and don't know how to use the mechanics on purpose, or 4. they spent a few hours level grinding until they could beat monsters with the "Fight" command, then complained that the game was too easy and blamed the devs.
As annoying as these players can be, I think they do have a point when it comes to things being mandatory. If a game can be beaten without the use of certain mechanics, then do those mechanics really matter? If the game can be beaten just by level grinding and button mashing, then is the game badly designed?
I think the counter to this is to make sure that the mechanics are actually required. Want the player to learn to use the "Guard" command? Give enemies an attack that will kill the player if they don't Guard (and obviously some warning the turn before). Want the player to learn to charge and use Limit Breaks? Make a boss that can only be hurt by Limit Breaks. Want the player to learn enemy weakness and resistances? Make enemies that block any attack they aren't weak to, or counterattack when hit by something they resist. If there is something you want the player to learn, then actually test them on it repeatedly. I won't cram info down the player's throat, but I'm under no obligation to let them see the ending unless they learn to play the game properly (no matter how many times they have to die to make it stick).
I'm planning on having a dedicated tutorial area the players will be directed to but not required to engage with. I'm also going to put an instruction manual of sorts that fully breaks down the game's mechanics in the inventory and make it clear the player is free to make use of it anytime. I've never liked having tutorials forced on me, especially when they're long and overdrawn. At the same time, not having any sort of tutorial is equally as aggravating, so I figure this is a good compromise between the two extremes.