In order to understand the concept of a smart contract one has to make a shift in their mindset - from thinking about Computer Science, blockchain, transactions to remembering how physical world works, about people interacting and proving something to each other. Imagine that there are no computers, they don't exist. After you design the interaction between humans and the way they can prove something in trustless or anonymous environments, the matter of digitalizing it by designing protocols that can fit it into computer and internet world becomes simply a question of application. You have to do first things first, meaning to design the game theory between humans and only then put time into contemplating computer science possibilities to make it work in digital form. This is also the best approach while trying to understand RGB.
So, what is a smart contract in this perspective? Smart contract is the way to enforce the fulfillment of a certain agreement between humans without an external centralized agency (military, government, court etc). Say, you don't have a physical contract and the parties of the agreement are anonymous, meaning you can't use physical force to make them follow the agreement. If in these conditions there are economical incentives to make the fulfillment of the agreement happen without applying any physical enforcement - this is what a smart contract is. As you can see, it has nothing to do with Computer Science per se. Computer Science can help to solve cryptographic part of the situation, can make it more efficient working over Internet and not requiring physical presence, but it can't solve the game theory problems. For that you need to use economics first. And if you analyse the smart contracts from that perspective, you will understand that you have to distinguish many things, for example ownership rights (ownership of different assets defined under that conctract) from the contract states (under which conditions the contract exists currently, as each contract between humans defines certain, let's call them, state machines). Thus we can say that the contract defines an event-consequence algorithm 'if this happens then that happens'. And of course, each of these algorithms also needs to follow certain verification rules. If you think about client-side validation in this regard, it is easy to create parallels and understand that in the described scenario you need to run client-side validation with single-use seals (without any blockchain). Let's imagine someone gave you $10 for you doing something or paid you for coffee. When you got this bank note of $10, you perform a client-side validation: you look at the bank note, you touch it with your hands, you check the watermarks, and you either accept it or you don't. That's the client side validation happening without any computer being involved. Also, in this situation you don't need to have all the information about every single other note that ever existed (no need to store the global state). And the only thing RGB adds in this regard is it simply puts this paradigm of client-side validation into a digital world, utilizing cryptography such that you could do the same, but in anonymous way. This and similar use cases can be seen in many other situations beyond finance. And that's why we say that RGB covers smart contracts use cases and different enforcement rules under them, while still having the game theory designed outside of its scope.