Remote Query Block versus Live Feed
Live Feeds and the Remote Query Block, for the most part, have the same capabilities in terms of being able to make requests to APIs.
They can both make GET and POST requests (although data sources can't handle less common HTTP methods like PUT and DELETE but the RQB can). There are some high level capabilities in data sources, like handling basic auth and some OAuth support which would need to be implemented more manually with an RQB, but are still doable. The main differences are in what causes an API call to be made and in how the response is handled.
Timing of the call is a key difference
With the RQB, the request is made when the block is "drawn" on screen, i.e., when the view (or layer) loads and, when the block (or view or layer or parent block) is refreshed.
With a remote data source, the request is made when the app thinks it needs the data and doesn't have it or when a user executes the Refresh Data Source action with Request Immediately checked. "When the app thinks it needs the data" is mainly when it tries to load a block that uses the data source and it doesn't already have data or the data has previously been marked "dirty" with a Refresh Data Source action without Request Immediately checked. Essentially, data sources are designed to be intelligent/kind of magical in how/when they actually request data whereas RQBs are more straightforward and consistent.
No difference regarding filters
Regarding filters, when we use a filter with a remote data source, we're not filtering the data we get back. Rather, we're sending a parameter with the "filter" value to the server, and that value controls what's sent back in the response.
So any "filter" you can "apply" with a remote data source you can also "apply" with a remote query block by specifying the same parameter/value in the RQB's request. In other words, adding a filter on a remote data source is equivalent to adding another parameter to your RQB. In short, you can apply the exact same "filter" because it's something the server handles, but you can't iterate over the results or have the app recognize them as a list.
Another key difference: Iterating and keeping the response versus one time use
The difference in response processing is that data sources tie into a mechanism that's integrated throughout the platform that lets the developer iterate over data as if it were a database table with rows (records) and columns (fields).
With a remote query block, you can specify paths to extract into variables, but that extraction is done once and then the response is discarded. With a data source the response is kept. So when there is a request for given field for the current record we'll extract it from the response if we haven't pulled it out already and cached it. So in practice you use the RQB in circumstances where you're mostly concerned about the side effects (defined as anything that happens other than sending you back a response) such as when you want to update or delete a record: With our Cloud Collection API those operations will return the deleted or updated record, but you're doing it because you want to change the data in the database, not because you want to see the value of the record—or when you're looking for a single record or value, such as when you're making an authentication call and need to get back an authorization token. If you need to display a set of records, data sources tie in with blocks like the pattern to enable you to display each row in the data source.