There is no inherent problem with using large graphics. The issue being discussed in the forum posts you found are most likely talking about texture page management, which is a part of game development that is often forgotten or neglected and then later bites developers in the back when they least expect it.
The core principle here is that all graphics are placed onto so-called texture pages.
Imagine a texture page to be like a palette that you can use to draw things to the room.
Now imagine that you're a painter. You can have as many palettes as you want, but you can only ever hold one of them at a time.
If you want to draw something that isn't on the palette you're currently holding, you have to put it down and pick up the right one before you can resume drawing. This swapping of imaginary palettes is what we refer to as a "texture swap", and it takes additional time on top of drawing that can sometimes be avoided with proper texture page management.
Texture page management refers to the strategy of placing graphics which will often be drawn together on the same texture page. For example, if you have a various enemies in a platformer game, it's not too uncommon to place them all on the same layer to ensure they will be drawn at a similar depth.
When left alone, the texture packer tries to fit sprites into texture pages as tightly as possible, but doesn't exactly care what it's putting where - more like how much it's putting onto a single page. In the worst case, it will end up putting enemy sprites across several texture pages (because there may be other, larger graphics that are being prioritized to put onto texture pages as early as possible), even if they could realistically all be put on a single page.
With that setup, whenever your enemy layer gets drawn, texture pages would be swapped left and right, which contributes to lag. The more enemies are being drawn at the same time, the higher the chances of more and more swaps occurring, and eventually, you'll end up with a relatively simple-looking 2D platformer game that barely runs at 60 FPS for no apparent reason. Even worse, whenever you spawn any particle effects, the game slows down to a crawl.
... and then you notice that your enemy sprites and particle effects are scattered all over your generated texture pages, and this seemingly useless and totally automatic "feature" that lets you choose where your sprites go will suddenly descend from the heavens as your game's holy savior from eternal suffering in the depths of lag hell.
As you may have noticed, the scenario I'm describing mostly deals with multiple smaller sprites being drawn. With big graphics, the situation looks a lot different.
Texture pages have maximum size. At some point, it might be impossible to put more than one image onto a single texture page, so it's easy to jump to the conclusion that because texture swaps are bad and will spell doom upon your death, it should be impossible to make a game that uses graphics so large that they barely fit on a texture page.
That would be true if a single texture swap had a massively detrimental effect on your game's performance. In reality, it is perfectly normal to have a certain amount of texture swaps. That's why we can manage our texture pages: So that we can ensure to keep this number as low as possible.
To catch the follow-up question: Exactly how many swaps are okay to have is hard to define, as it depends on exactly what is being drawn in your game. Ideally, the maximum amount of swaps is equal to the amount of texture pages you have. Assuming that you're drawing at least one sprite from each texture page, this indicates that your texture page management is successfully adapted to the order in which you're drawing graphics. The end goal is not to avoid swaps altogether, but to avoid situations where you keep swapping back and forth repeatedly, as those are the situations that have the potential to cause exponential explosion.
An example of the above: Imagine you're drawing a segmented health bar and are drawing it using two sprites: One background sprite that will always be drawn for each segment, as well as two sprites for a full and empty segment, respectively.
The health bar is drawn segment by segment by first drawing the background sprite, then drawing the full/empty sprite in a loop.
If the health bar has two segments and all sprites are on the same texture page, you'll end up with a maximum of one swap (if current texture page doesn't contain those sprites).
If the health bar has two segments and all sprites are on different texture pages, you'll end up with a maximum of four swaps (first background, first full/empty, second background, second full/empty).
Enter Exponential Explosion. If the health bar has 10 segments and all sprites are on different texture pages... that's twenty swaps just from a single health bar. Also, there are about 30 enemies on the screen which all have a health bar. That'll put the counter at 600 swaps. Enjoy the slideshow, and don't blame the ultra advanced enemy AI.
To put that into perspective, you could have a massive amount of full-screen graphics being drawn in your game to get anywhere close to 30 enemies with 10-segment health bars, as you are most likely only drawing these graphics once per frame (for a typical Phoenix Wright game... background, text box, some text (Nocturne forbid the letters to somehow end up on different texture pages!), character, OBJECTION! - that should be a maximum of five swaps on top of any internal swaps if you check it with the debug overlay). The exact performance hit induced by a swap may differ between differently-sized texture pages, but that should pale in comparison to exponentially exploding swaps.
An entirely different concern is memory - not video memory, but RAM - as texture pages need to be stored in RAM as well so that they can be quickly loaded into VRAM on demand. With high resolution graphics, you may have to dynamically load and unload graphics (using functions such as sprite_flush and texture_prefetch) to prevent the game from running out of memory and crashing, as (for this example, on Windows) games are created as 32-bit executables, which are limited to around 2GB of RAM usage by the operating system.
