Directly, if you do not need to save data to the device, you do not need SQLite.
There's no reason to add anything to your code that you will not use (see exception).
Let's go to your example.
If you will send all the information to a Web Service and return all the data from it, you will not use SQLite. Now, your CRUD may or may not have been in vain, it depends on how your system is architected. If you will save the data in the Web Service, you just need to change how to save a CRUD SQLite to send data to the Web Service. The way you do this depends a lot on the architecture you're using, but it was just an example.
So should not I use it?
Well, we've skipped some of your specific case and talked about applications.
Need to use does not have, however, is very common to use because of connectivity issues. Not always will the person have access to the Internet, and losing everything that was done (depending on the application) would be a bad experience for the user.
Now, if you want your app to work only when your device has internet, you do not need this data.
Going a little further, even though your application will return all data from the Web Service, there may be cases where it is more performative and less "costly" for the user to perform a single query in the Web Service and save the return in SQLite. Imagine the system making a request to the Web Service to each page just to get the username of the logged in user? This would consume the internet and there would be several requests to the Web Service that could be handled just by saving the data in SQLite.
Now, since by @bigown in comment , you can not reply say whether you will need it or not. Only you know the scope of the project and what it will really need.
