There are multiple parts to your question so let's group them;
The downsides
A developer will be forced to attend all ceremonies for each project
If your developer is split across multiple projects (let's assume all are Scrum) then they will be attending multiple stand-ups, sprint planning, retrospectives and reviews. That is not an efficient use of the time and it's unlikely the ceremonies will be in synch, they may even overlap forcing the developer to miss critical project context
Context switching
Miller's Law states we have the ability to hold onto 7 +- 2 items in short term memory. These memories can last for up to 18 seconds and are refreshed by the original context. Any distraction will affect short term memory from stress, noise to music and loud conversations.
Now imagine you’re a programmer, trying to solve a problem what requires you to hold multiple items critical to both understanding and solving the problem. Next Imagine a PM, running over to your desk and asking the following.
“I need to show you this bug on the test environment as the client sees it and is wondering if it will be in the release next week”.
Suddenly the developer is forced to operating in a different context and is to recall multiple different items to answer the question, that in truth doesn’t need to be answered anyway. Also, the more complex the question and the longer it takes to answer the more short term memory is used on this new task.
For a developer to return to the original state depends on its complexity. Which can require anything from 5 to 30 minutes? Now imagine multiple interruptions and you can easily see how productivity will flatline.
With two or more projects you just doubled the context switching...more people, more risk of context penalties.
Lack of Cross-Functionality
Without being dedicated to a single Scrum it is unlikely the developer will have the time to cross-skill into new technologies and conversely, will have almost no time to be able to cross-skill or pair program with anyone else to coach them into a cross-skilled state
Developer Confusion
The developer will waste valuable cycle time wondering who takes precedence over their time - Product Owner A or Product Owner B. It is likely to change from Sprint to Sprint.
Risks
Developer has a poor appraisal
With his/her time split across multiple teams it is unlikely that either team will be able to give honest feedback to the developer and the very real risk is that both teams feel unsupported and the developer is provided with negative feedback which is reflected in performance related appraisals, bonuses etc.
It is not a sustainable working practice
Working across dual teams is not sustainable and is in direct contravention of the Scrum idea of "sustainable working." In addition it is likely to make cross-team working acceptable and will encourage further time splitting from other developers, testers and even the Product Owner. Disastrous for an Agile transformation and indicative of organisational dysfunction.
Team ethos and Developer morale is destroyed
When you are a part of two teams, you are a part of no team. The Scrum teams become ever closer and the switching developer is just considered "that person they need to include".
The Developer is increasingly stressed and pressured and tacitly encouraged to "find the time" to offer full capacity to both teams. It takes a special character to be able to say "no" and simply leave their work at the door.
Planning becomes inconsistent and impossible
Without being able to dedicate themselves to a project the velocity of the team will become inconsistent as stories forecast at the start of the Sprint are left undone lowering the velocity to an artificial level to cope with an absent team member
Both teams are crippled by absence
Should the developer leave or go absent you have now crippled two teams, rather than one. The risk is not shared; it is doubled. Especially with no cross-skilling.
The Developer becomes a bottleneck
The WIP limits of the teams are impaired because stories are blocked by a single developer and the time they can devote back to original team to progress a story.
The Organisation refuses to tackle a resourcing problem
A shared resource is indicative of poor management not investing in cross-functional training, not hiring needed resource, not incentivising staff to remain in the company, not promoting people to the roles they are aspiring to or not accurately forecasting the book of work for the year (or possibly all five).
It is important to realise this symptom may be the start of a death spiral.
As resource bottlenecks arise, the resource/trade is piled with more and more pressure which forces them to leave making the bottleneck worse increasing the demands which means more resource leaves...
...a blight which affected the British Army for Combat Medics from 2000 until present. As the staff left and were not replaced, the remaining medics were sent on more frequent combat tours increasing their rate of sign-off leading to even MORE frequent tours for remaining Medics until the system collapsed and economic intervention was required at massive expense to the Government.
Quality Control
Thanks to @MrHinsch for adding this as a risk. A developer split across two teams is likely to sacrifice quality for speed leading to a poorer overall product.
It is closely tied to the behaviour of drive-by ticket tracking where developers are more focussed on getting the story ticket into Done than they are about actually getting the story Done Done.
Summary
Overall, the effectiveness of both teams are at risk and the developer can feel overworked, isolated and professionally penalised leading to real-world economic consequences.
