TLDR;
Separate your view and business logic, or don’t – WordPress doesn’t care either way. Additional template engines aren’t necessary.
Start small developing with vanilla PHP & WordPress; just build something that works, then separate it’s view and business logic. Continue refactoring as you learn and the project grows. When you’re comfortable with theme and plugin basics, consider migrating to a third-party template engine, and whether or not such a migration really contributes to the project’s objectives.
Extension Structure
I would like to get max amount of info on how the WordPress implements the separation of presentation from code.
How separation of view and business logic in WordPress itself is implemented varies considerably throughout the codebase, and is generally of little concern to theme/plugin developers. I won’t delve into it here because it is a lengthy subject, and I don’t believe it was your question’s intent.
Themes and plugins alike have a single file-based entry point which WordPress executes at the appropriate time. Third-party code can then subscribe (“hook”) to various events (“actions”/”filters”) in order to interface with WordPress.
Outside of these restrictions the developer is offered complete control over their code structure and organization – there are some file-name-based conventions for automatically loading template files, but the developer needn’t leverage this behavior. To separate view logic from business logic in a theme or plugin, you really just separate it. View and business logic have no inherent coupling in WordPress any more than in PHP itself. The line determining which code qualifies for which role is usually apparent in the WordPress APIs that the code leverages – views tend to only present data and make use of the WordPress “template tag” functions, while business logic is usually devoid of HTML and template tag calls.
Template Engine
One way or another, it’s possible to use virtually any template engine with WordPress. But note that you neither have to select another template engine nor write one yourself. PHP by itself is more than adequate as a templating language. Consider that depending on the size and scope of your project, adding an additional template engine may unnecessarily complicate development and maintenance (and licensing, and update workflows, etc.).
Unless you have specific reasons for choosing a template engine here and now, I’d recommend familiarizing yourself with basic theme development using PHP and WordPress before deciding on a template engine such that you have a better frame of reference for selecting what you actually need rather than just adding popular code.
The Best Tool
This would need to be the best thing that exists as the scripts are planned to be for sale.
There is no one-size-fits-all solution for the “best” when it comes to software, which is why there is such an incredible variety of solutions out there. Here too, what design pattern you follow and what templating engine you use are entirely subjective – the only way to select the “best” option is to evaluate the needs of your project against the strengths and weaknesses of the available solutions. Even then you’re likely to encounter opinion-based impasses which may require flipping a coin or simply following intuition.
If this is going to be a long-term or large-scale project, the time spent familiarizing yourself with each possible solution will be time well spent. Every developer has the experience of getting halfway through a project only to discover they chose the wrong tool for the job, and now must refactor significant chunks of their code-base or forge onward with ugly hacks and work-arounds. I’d recommend against choosing your technology stack based on ambiguous recommendations – what is “best” to some may very well be the worst thing for your project.