Sharepoint - Will the new SharePoint FrameWork increase speed?

"tells my Client all the Front-End dev I did in the past is oldfashioned"

Depends on what you did and what he is talking about... in my perspective SharePoint is going client side just like its Windows operating system because of loading speeds. That being said the key here is to look at the trends in what is being picked up at a fast rate. The framework that has gained huge momentum over the past couple of years and hasn't slowed down is AngularJS 2 and MVC. React is good and is down to preference. So far Angular seems to be the best choice for adoption and you can just see it in the job market. Most ask for angularJS experience or knockoutJS.... by far jQuery simply still the best adopted but Angular is catching up. Doesn't matter what any MVP or master would say it's what the masses want to use will decide the trend and how easy it is to adopt as a dev language.

To the issue at hand. How are you loading the images.. problem with SharePoint Online like any website has to do with the ISP load, the assets on the page like your images your pulling from a list and the fact that you're more than likely on multi-tenant mode so the more tenant you have and how many clients are loaded onto the server at any given time will effect the performance. Going dedicated would be the solution but is very expensive so the solution would be to use other techniques to get the info you need.... have you tried JSOM instead of rest to query? also in code its best practice to load the page first and then query for data using rest to give a more realtime effect and feel.

Speeding up SharePoint for downloading assets is vast in the techniques like using smaller sizes to delay downloading and object cache:

https://support.office.com/en-us/article/Tune-SharePoint-Online-performance-f0522d4a-fbf4-41f9-854e-c9b59555091d?ui=en-US&rs=en-US&ad=US&fromAR=1

The fact you mention rest, I presume it's webpart or app on a page that is getting data from rest calls? Update your rest so it returns less data in a controlled manner if possible and index columns within the list or utilize SharePoint automatic index management feature.

Sorry to be vague but need to be a bit more specific on where the issue is occurring if it's overall or on specific pages/lists.

Just to make it clear in SharePoint Online and 2016 the rest services have improved and are likely to stay! If you want to know what happens in the backend well this happens:

Maybe this MVP is privy to upcoming tech from Microsoft that Microsoft hasn't noted in MSDN but to my knowledge rest or csom is the correct call with batch processing as one call regardless of what container I use be it in a webpart, iframe or SPFx webpart. SPFx still uses REST or Webhooks to get/post data.

As I noted that your issue is not what you're using but how you're using it. Yes SPFx will increase load time as it's not an iframe but you can run just like an approved add-in but this is purely the loading of the SPFx webpart that is used within the page (not how it gets the data). As an example running SPFx webpart vs add-in app side by side that both do nothing.... SPFx will win as it's purely clientside when run with. If you were to get data in both of them to render images that the call will still be the same using either csom or rest. So yes SPFx will be slightly fast as its container is JavaScript based so the initial loading is faster but getting the data is still the same and so is rendering unless you code it otherwise as noted earlier in my post.

Have you tried other browsers and at different times to load the page? as noted apart from above the only other thing you can do is go dedicated which Microsoft would love you to do.

Now you have posted an update, I can see it's not to do with your code but rather the server itself. As noted in my last comment at the end it has to do with server load and how many tenants are on the virtualised server at that given time. If you were to run the test again now has it improved or run it over the weekend has it improved? If it does than you can't do much about ttfb as that is back end and to do with the server. I would say get a better package, just what Microsoft wants. Also Angular2 has improved vastly over Angular1 and if it's such as massive issue with DOM updates than there are others just as good as react if not better than have just come out like Incremental DOM (yes another Google product). Businesses like AngularJS and Knockout but developers seem to adopt React but these days it's not much different unless the project is big and complex then it's important to choose the right one.

EDIT

as this is still widely read by the masses and voted on I thought i would update it.

I would assume the reason why the mvp has chosen react and suggesting react is that Microsoft has chosen it rightly so as its container based. That is why they have made the appfabric components available for you:

https://developer.microsoft.com/en-us/fabric#/components/

so seems that its Microsoft's preferred choice but you can still use multiple frameworks with each other.

I would be more concerned about learning TypeScript and how SPFx works. Then I would learn CDN and Azure. Once you have that you could make just about anything with any extension but even myself my preference has been React for its simplicity and speed. Other extensions are faster but little adoption which is key in trends:

king of the crops javascript

Just look at Emperor TypeScript in green! so to overtake javascript at these breakneck speeds once adopted properly!

as you state, SPFX doesn't have some special way to call REST endpoints that is faster. The sphttpclient object makes a standard web call (and uses the standard browser request underneath). Depending on how the original solution was implemented (iframes anyone?) it can be faster, in the same way that a SEWP is faster than an iframe. At the end of the day though, it's all javascript. What can also be faster is that with 1st and 3rd parties using the same libraries, you don't need to download different implementations of what is effectively the same code (I'm sure that there are numerous implementation of refreshing your auth token when it expires).

Our hope would be that, once people are familiar with the tools, it will be faster to write robust, complex solutions (5000 lines of pure js is a lot. Anders Hejlsberg wrote TypeScript to tackle js development at scale).

The performance #s you have at the top (downloading images, making REST calls, etc.) are going to be the same no matter what framework you use. We're working on improving the speed of both raw file downloads (the image gallery) and REST calls (which should also improve aspx requests as well), and those improvements will help everyone. There are also features you mentioned in previous posts to do with the CDN integration, which can help things like image galleries (if you are OK with the security aspects) and future work around secure CDNs.

As far as the wrap vs. write conversation, it's going to depend heavily on what the original code looks like. If it is tightly coupled to the current DOM, depends on global window variables, etc. it's going to be rough going. However if it has a clean separation (for example, you pass in the DOM element you want to modify, you pass in the window variable to your functions, etc.) then it should be much simpler. Throwing away 5000 lines of tested, stable, documented and understood code seems extreme. I would look at how it could be incorporated.

Disc.: all below is my POV only.

Is SharePoint Framework going to have influence on the download speed of assets? or access time to REST endpoints?

I strongly believe no it's not. Absolutely no influence.
You said they can track request tag - yes they can, but from the other side they are saying that for SPFx you can use any js library you want, that means I'm not restricted to use SPFx pre-built httpclient, I can use fetch or just vanilla xmlhttprequest.
With custom http client they are not able to track request-id and are not able to "optimze" request. If they are really doing some optimization for SPFx requests, in that case I think they should say "hey guys, use only this one, becasue it's blazing fast. Don't even think about something other than pre-built httpclient". But in reality we can use any and that's official.

How can we speed up dowloading Assets and accessing Endpoints?

That's a good question. For me images are loaded fast on my empty dev tenant. I think you need to try to find the root cause. First of all make sure that's not a permissions or too many files problem. Create a new library and put only one single image and measure performance. Too many items or too many unique permissions can slow down requests. If this for the whole tenant... I would that's a reason to raise a support ticket.