I know RESTful WS is an architecture all together, which is a new way of implementing Web Services over old fashioned JAX-RPC's.
In RESTful, we use @GET, @POST, etc to manage calls/develop resources. Same can be achieved using HTTP programming (both are stateless too). But what are other core main uses or need for bringing/implementing RESTful? As everything we do in it, can be done using HTTP programming (in which we use same methods)?
The question is comparing different things. HTTP is a protocol, while REST is an architectural style. This is like asking what a house does that a brick doesn't. It doesn't make sense. HTTP can be a building block of a REST application.
REST is not about HTTP or any particular protocol. REST is about applying the successful design decisions of the Web itself to software development. The problem is terminology. 99.9% of the so called REST applications around the internet aren't really RESTful, because REST became a buzzword to refer to any HTTP API that isn't SOAP. Some REST advocates gave up on fighting for the proper usage of the term and now refer to REST applications as Hypermedia.
Like the Web, REST is intended for software development in the scale of decades. REST makes it easier to evolve your application without breaking clients. Think about how today you can still access websites that were created decades ago, and almost everything still works fine. If you're creating software that has long-term objectives in the scale of several years, then maybe REST is adequate for you. If that's not what you really need, then getting REST right is not important. Just use whatever works for you, and at this point I think nobody cares anymore if you call it REST.