Ok maybe I can help or at least try ...

The backend and frontend frameworks don't really intersect at the CMS. They intersect if and when a project is custom written. Let's say the backend uses Laravel PHP framework for the backend with MySQL database and the frontend uses Bootstrap/jQuery. Using those frameworks gives you a base level of code to start from which is much better than writing or rather rewriting what's considered 'universal' code. Universal code is a bad name for the code which almost all projects are going need. LIke for the frontend, forms will need to be styled and they should be styled so they are consistent across browsers/devices. Which I imagine you understand. Now the backend framework provides functionality like Routing requests from URLs to API calls, Database access (providing an abstraction layer to multiple database types through a common interface) and more. It does not include the structure of the database tables, nor does it provide the business logic specific to the application.

Bad analogy would be imagine some provides the frame of a house and you finish it off by adding the interior/exterior walls, roof etc.

The specific WP case, WP is the backend. Which means you don't have to worry about the backend. It's a house with bare walls and you pick the paint or finishing materials (the frontend). Now for extending the CMS, you are stuck using WP's available methods which is their plugin system which has it's own API and it has most of what a backend framework would provide.

Well when working with a CMS it is more difficult. Are you using git or some type of source control yet? Hate to throw something else on the fire but it's probably the most important tool outside of the required stuff.

How the pieces fit together .. first, frameworks and such are really optional. You don't have to use them so if that helps reduce the complexity start there.Going to an extreme, the only must is the HTML pages and that's just text files. So this hypothetical website is for someone else who will provide feedback and maybe additional content, it will require versioning (which means use git).

Steps : 1) create the project on github 2) checkout the project into my local WAMP setup (call it DEV). 3) write out the HTML 4) push a commit to github when I'm done. 5) FTP the files to a server on the web 6) client reviews & submits change requests (via email) 7) checkout project from github again 8) apply the changes 9) push the commit ....

That's probably the simplest possible development process. Single developer, single file type, etc. Adding CSS to this is as simple as creating a style.css file and adding it to the project folder and pushing a commit to github. Adding bootstrap or foundations to that setup is easy since I create a public/ folder with css/ and js/ sub-folders which house those.

Now how do you add the backend into that ? The answer to that is a package manager which is composer on PHP, npm on node.js. What does it do? It provides a means to install code automatically from a repository.

Let's use Laravel as the example here. Without a package manager, the developer would have to go to the Laravel website, download, unzip, move the framework files to the project directory and write some basic code to auto-load the framework (which is a fancy way of saying, initialize or make the framework available). This is bad for a few reasons. When committing the updated project to github it will now include the entire Laravel framework when there is no real need. It's hard to manage versions.

The package manager reads a text file from the project root directory which contains a list of required packages and it downloads those into the project and sets up auto loading for the developer.

How does this work with source control and deployment ?

You can make git ignore certain directories (the directory for 3rd party code) so when you commit the project to github, those files are not uploaded. Which means the only code in the source control repository is your code. When the site is deployed, the developer runs composer on the server to download the 3rd party framework code.

Simple right? Not even close to done is the problem.

How are databases handled ?

This is where the tools aren't quite there yet. The most important part is the structure of the database at the start of development. The simple method is to create the database tables and use a tool like phpmyadmin to export the sql for the tables. Copy that sql into a text file and put it into the project folder in a sql/ folder. Call it whatever you like and add a version number if necessary. Once you get into backend work (if you decide to), you can find more advanced techniques for dealing with databases.

CSS pre-processors

You may have heard of SASS or less, these are tools which provide some programming functionality to CSS files. Simple example: variables. Say the project has a primary and secondary color which are repeated throughout the CSS. Instead of typing out

rgba(100,100,100,.8);

repeatedly , it would be much easier to just type $primaryColor and that would let you change the rgba values across the entire CSS file (or files). And there's more to pre processors than just that. Problem is these have to be ran through their respective programs to generate the final CSS. Which is another step in the process.

Build Process

The process of building the final project can contain many different steps. Copying files, downloading them, running specific processes, etc to produce the final result. This is where build tools like Grunt, Phing or others comes into the process. Basic examples would be

run composer to install dependencies

run LESS to generate CSS

Minify the CSS/JS files

That's how the development process is evolving again on a basic level. There's parts I've left out like specifics on deployment and I just dropped FTP in as the default method to reduce complexity. And I didn't touch VMs or their tools (Vagrant,Docker,...).

Back to your specific case of developing WP themes. Let's deal with this first, bespoke isn't that great. I know a certain part of it is pride. You know, wanting to say "I built this whole thing". With themes, if you wanted to do bespoke, the smart way would be to build a base parent theme and base all future themes on it as child themes. If you want to use a frontend framework in a theme, the easiest way is to find a theme which incorporates the framework and make your theme a child theme of it.

From the above tools, the package manager is probably more trouble than it's worth at this stage and with WP. The other tools could be useful though it just depends on how much time you have to devote to learning them and adding them.

Yes there's lots of stuff to learn some of it's frameworks, some of it's tool chains. Ultimately you have to be able to filter and judge what is useful to you and what's extra. There's nothing which says you have to use everything. If you don't like it or deem it unnecessary , go back to the basics and use what makes you the most productive.