As you say, if your only goal is ShoeBot this (scripts, functions, etc.) is a great way to go. One of the key points of deep learning approaches is that you hav

As you say, if your only goal is ShoeBot this (scripts, functions, etc.) is a great way to go. One of the key points of deep learning approaches is that you have this abstract, powerful computational device that is trained to extract the necessary features and also perform the task jointly - and it just happens to be a ShoeBot due to the training data. This usually results in improved performance along with "ease of use" in transitioning to new but related applications. A model just happens to be a ShoeBot when trained on specific data, but ostensibly a person or company could make ShoeBot, CarBot, ApartmentBot, etc with the exact same approach, given enough data. This is very different than a workflow of "craft tons of features for domain X, write custom scripts/conversation logic for domain X, etc.". These choices between feature based approaches and "deep" techniques are tradeoffs reminiscent of "you aren't gonna need it" versus "room to scale", but in the ML algorithms you choose rather than the software stack/implementation. It depends on things like how much data you have, how much compute you are willing to pay for, how many users you expect, and so on - but neither approach is necessarily wrong. In general if deep learning approaches don't roundly beat feature engineered or hand crafted approaches, you don't have enough data or are trying to shoehorn (pardon the pun) a solution that doesn't fit. Right tool for the job and all that.