Hybrid encryption with RSA and AES versus spliting into multiple RSA messages?
The question has several aspects:


it asked (initially) about any security issue in breaking a piece of data into separately RSA-encrypted chunks;
it asks what's the weak link in the security chain when doing hybrid encryption with a 256-bit AES key transfered enciphered using 2048-bit RSA;
it asks how much slower 2048-bit RSA would be for bulk encryption, compared to AES-256;
it (formerly) outlined a protocol where a public key is RSA-enciphered (causing the Plaintext is too long error); that protocol turned out to be unsafe not protect the confidentiality of data enciphered with that public key, basically because that public key was sent enciphered, rather than signed.


On the first aspect: if the goal of encryption is limited to protecting the confidentiality of some data (which is the only goal assigned to encryption in its modern definition), and RSA encryption is done properly (that is, with random padding), then there is no security issue, only performance and message size issues.

However the protocol formerly outlined used RSA encryption for other purposes than encryption. So maybe breaking the encrypted material into chunks worsens things; like, multiple cryptograms can be reordered by an adversary.



When doing hybrid encryption with 2048-bit RSA used to transfer a 256-bit AES key, the weak link is, from an academic point of view, the 2048-bit RSA key. According to the multiple sources considered by this well-respected website on key length, 2048-bit RSA is somwhat less secure than a block cipher with a 128-bit key, which itself is (theoretically) $2^{128}$ times less secure than a block cipher with a 256-bit key. Two levels of explanations to that:


Qualitative: in RSA, an adversary is given a lot of information about the key (the whole public modulus); whereas in AES, the key is assumed secret, being exposed to the adversary only through the complex layers of the cipher.
Quantitative: factoring $N$ is known to require less than $\exp\Big(\big(\sqrt[3]{\frac{64}{9}}+o(1)\big)\cdot(\ln N)^{\frac1 3}\cdot(\ln\ln N)^{\frac2 3}\Big)$ operations, and plugging $N\approx2^{2048}$ into that, ignoring the $o(1)$ term, gives less than $2^{117}$.


But reality is, the true weak link (beyond using a bad protocol) is the ability to keep undisclosed the secret material involved (e.g. the secret AES key and the private RSA key). Many things conspire to make this hard, both for RSA and AES, including implementation goofs, side channels, and NSA-planted backdoors.



How much slower RSA-2048 is compared to AES-256 depends on many things:


Is the cost of key generation to be considered? That is the case in the protocol formerly described, where a 2048-bit RSA key is generated for each user connection, and used only a few times per session, unquestionably making RSA key generation the performance bottleneck: generating an RSA key is much slower than using it, and can be like $2^{20\pm12}$ times more costly than AES-256 key generation or encryption (methods used for RSA key generation vary widely, and what we should include on the AES-256 side is unclear).
What is the hardware? If there is hardware for AES, but not for RSA, which is common on many modern CPUs, AES-256 encipher and decipher bulk data like $2^{20\pm 8}$ times faster than bulk RSA can. Even with hardware for RSA but not AES, like on this Smart Card with ARM Cortex M3 CPU, RSA is slower than AES is.
What is the software? Poorly written software can slow anything without limit. It is very common that two deployed implementations of a cryptographic algorithm differ in performance by a factor of $2^4$ on the same hardware.
Are we considering RSA encryption or decryption, and in the former case what's the public exponent? With $e=3$ and simple implementations, RSA-2048 decryption is $2^{10\pm1}$ times slower than encryption is; make that $2^{7\pm1}$ for $e=65537$.
The size of what's encrypted: AES's speed advantage is least when the data enciphered exactly fits the capacity of the RSA encryption scheme.




On the last aspect (now no longer part of the question):


Whatever exactly the protocol outlined was and aimed at, it was bound to be vulnerable to a Man-in-the-Middle attack during the "upload" of the "uniquely already known (user) public key"; a sure sign is that the client starts without any credential.
The protocol included an explicit step of encrypting something designated as "public key" (see end of step 4 in the protocol); this is a tale-tale sign of a design error.
Even if that "public key" was not made public, the confidentiality of commands normally sent enciphered by the user using that key (in step 5 of the protocol) was not ensured, for an adversary could inject another public key to be used instead.
In some most common uses of RSA for signature, an unknown public key is easy to infer from a few signatures;  keeping that public key confidential during its transfer does not prevent its later disclosure when and if it is used for signatures (as alluded in comments but not in the former description of the protocol).